| 導購 | 订阅 | 在线投稿
分享
 
 
 

講解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- 王朝網路 版權所有