| 订阅 | 在线投稿
分享
 
 
 

讲解InfoPlus与Uniformance PHD的SQL支持

来源:互联网  宽屏版  评论
2008-07-09 05:37:21

这篇论坛文章(赛迪网技术社区)主要介绍了InfoPlus与Uniformance PHD的SQL支持及笔者的个人观点,详细内容请参考下文:

应该说这两个实时数据库都很不错,在工业控制领域有着广泛的应用。由于我们在MES上的特殊需求,我们尝试用SQL方式查询历史数据,而不是直接调用其API。虽然API方式在速度上会快些,但是一些难以解决的古怪问题让我们最终还是放弃了。

首先做的InfoPlus,用的是ODBC连接,发现一些问题,或者不是问题,只是我们觉得不太好的地方:

历史值明明都按照IP_TREND_TIME排序了,但是在SQL语句中若对这个时间用了MAX或MIN,速度不是一般的慢,去掉就好了

自己的诡异的日期格式,一定要按照它的来,其它格式的不行。有个日期转换函数有问题,并且会影响速度。具体是哪个函数就不记得了,呵呵。最搞的是,某个日期转换函数会给出“4月17日 2006年” 或类似的中文年月日,让人苦笑不得。我只好把中文字符再替换回来。

在WHERE字句中如果用了不是它的日期格式进行比较,它并不报错,但是它会傻乎乎的把该点的所有历史值都找一边,速度自然慢得吓人。

当然,我们不能拿实时数据库的SQL支持去跟大型关系数据库做比较,但是这样的结果也确实让人有些失望。

不过,没有最差,只有更差----让我们来看看Uniformance PHD。

PHD的SQL支持有两种方式:Visual PHD和OLE DB。前者是个ActiveX控件,我开始也是采用这种方式,但是在最后封装成web服务时却无法调用这个ActiveX控件了,无奈之下只好转向OLE DB。哪位大虾知道C#写的web服务如何调用本地的ActiveX控件,麻烦告诉我。

PHD的OLE DB连接字符串是这样的,有些参数得看具体情况再作修改。不过现场实施的人一般都不会去改这些默认设置。

ConnectionString: Provider="HwPHDProv.2";User ID=;Data Source="10.121.2.35";Extended Properties=;Persist Security Info=False;Location=TOTALPLANT

原始的历史数据都保存在表IP_PHD_RAW中,点的配置信息如数据类型等都保存在表IP_PHD_ONLINE_TAG中。查询历史数据时一般都要对时间戳作比较,PHD中支持NOW操作,时间戳格式要严格按照“2006-04-17 08:00:00”来写,不能少0。千万不要查询没有历史数据的时间段,否则会出异常的。

接下来就让我们来看看PHD的SQL支持上的不足吧:

1.不支持统计操作,如sum,avg,max,min等等

2.不支持字符串模糊匹配

3.where字句中仅能对点名、时间戳、点号进行比较,并且点名只能比较是否相等

在测试过程中,我发现第一次查询的速度都特别慢,后来仔细想想,估计原因是这样的:

由于点的配置信息是存放在Oracle数据库中,而Oracle数据库服务器和PHD服务器并不是同一台机器,因此第一次访问都要通过ODBC去连接Oracle服务器,获取点的数据类型,这样速度就比较慢;已经访问过的点的数据类型信息会被我缓存起来,因此以后的访问速度都会快些。不知道这个猜测对不对,呵呵。

以上我对两个实时数据库的SQL支持都颇有微词,因为我觉得其SQL支持与大名鼎鼎的实时数据库本身相比,实在不是很般配。

我们现在也在做自己的实时数据库,面对前人的优势和不足,我们,或者说,我,能将SQL支持做成什么样子呢?

这篇论坛文章(赛迪网技术社区)主要介绍了InfoPlus与Uniformance PHD的SQL支持及笔者的个人观点,详细内容请参考下文: 应该说这两个实时数据库都很不错,在工业控制领域有着广泛的应用。由于我们在MES上的特殊需求,我们尝试用SQL方式查询历史数据,而不是直接调用其API。虽然API方式在速度上会快些,但是一些难以解决的古怪问题让我们最终还是放弃了。 首先做的InfoPlus,用的是ODBC连接,发现一些问题,或者不是问题,只是我们觉得不太好的地方: 历史值明明都按照IP_TREND_TIME排序了,但是在SQL语句中若对这个时间用了MAX或MIN,速度不是一般的慢,去掉就好了 自己的诡异的日期格式,一定要按照它的来,其它格式的不行。有个日期转换函数有问题,并且会影响速度。具体是哪个函数就不记得了,呵呵。最搞的是,某个日期转换函数会给出“4月17日 2006年” 或类似的中文年月日,让人苦笑不得。我只好把中文字符再替换回来。 在WHERE字句中如果用了不是它的日期格式进行比较,它并不报错,但是它会傻乎乎的把该点的所有历史值都找一边,速度自然慢得吓人。 当然,我们不能拿实时数据库的SQL支持去跟大型关系数据库做比较,但是这样的结果也确实让人有些失望。 不过,没有最差,只有更差----让我们来看看Uniformance PHD。 PHD的SQL支持有两种方式:Visual PHD和OLE DB。前者是个ActiveX控件,我开始也是采用这种方式,但是在最后封装成web服务时却无法调用这个ActiveX控件了,无奈之下只好转向OLE DB。哪位大虾知道C#写的web服务如何调用本地的ActiveX控件,麻烦告诉我。 PHD的OLE DB连接字符串是这样的,有些参数得看具体情况再作修改。不过现场实施的人一般都不会去改这些默认设置。 ConnectionString: Provider="HwPHDProv.2";User ID=;Data Source="10.121.2.35";Extended Properties=;Persist Security Info=False;Location=TOTALPLANT 原始的历史数据都保存在表IP_PHD_RAW中,点的配置信息如数据类型等都保存在表IP_PHD_ONLINE_TAG中。查询历史数据时一般都要对时间戳作比较,PHD中支持NOW操作,时间戳格式要严格按照“2006-04-17 08:00:00”来写,不能少0。千万不要查询没有历史数据的时间段,否则会出异常的。 接下来就让我们来看看PHD的SQL支持上的不足吧: 1.不支持统计操作,如sum,avg,max,min等等 2.不支持字符串模糊匹配 3.where字句中仅能对点名、时间戳、点号进行比较,并且点名只能比较是否相等 在测试过程中,我发现第一次查询的速度都特别慢,后来仔细想想,估计原因是这样的: 由于点的配置信息是存放在Oracle数据库中,而Oracle数据库服务器和PHD服务器并不是同一台机器,因此第一次访问都要通过ODBC去连接Oracle服务器,获取点的数据类型,这样速度就比较慢;已经访问过的点的数据类型信息会被我缓存起来,因此以后的访问速度都会快些。不知道这个猜测对不对,呵呵。 以上我对两个实时数据库的SQL支持都颇有微词,因为我觉得其SQL支持与大名鼎鼎的实时数据库本身相比,实在不是很般配。 我们现在也在做自己的实时数据库,面对前人的优势和不足,我们,或者说,我,能将SQL支持做成什么样子呢?
󰈣󰈤
 
 
 
>>返回首页<<
 
 热帖排行
 
 
 
静静地坐在废墟上,四周的荒凉一望无际,忽然觉得,凄凉也很美
©2005- 王朝网络 版权所有