全國最多中醫師線上諮詢網站-台灣中醫網
發文 回覆 瀏覽次數:12173
推到 Plurk!
推到 Facebook!

李維大師談ODBC, OLEDB, ADO和dbExpress連結技術的前世今生及使用時機

 
GrandRURU
站務副站長


發表:240
回覆:1680
積分:1874
註冊:2005-06-21

發送簡訊給我
#1 引用回覆 回覆 發表時間:2008-09-20 13:29:20 IP:118.167.xxx.xxx 未訂閱
[緣起]---廢話內容,可以直接跳到「主文開始」觀看
話說之前在Delphi/C Builder 2009試用版開放下載了裡,看到juneo大提到ADO會取代DATASNAP的說法,以及careychen大在OLEDB與ODBC的效能中所測試的結果,對寶蘭/CG所提出DBX的"好"有所動搖。
所以到李維大師的部落格針對CG DELPHI2009的效能問題提出擬問。而李維大師也對於些擬點做了解說,也把這三者之間的前世今生再度說明一次,我覺得對於新手在決擇資料庫的時候,也能提供很棒的參考指標,而熟手在維護或移轉時對新技術的掌握也能有所提升,故將我所提出的問題及李維大師的回覆轉PO至此,提供給各位同好們參考。

[提問始末], Q:←指的是小弟我,A:←指的是李維大師
Q. 老師,我看delphi2009有針對ado做新增的技術,但dbx反而沒有,cg是準備像cb6時期一樣地拋棄dbx嗎?

A. MS已經不發展ADO了, Delphi 2009的dbGo是維持ADO的相容性而已. DBX4有許多的功能, Metadata, driver都支援Unicode, 更好的執行效率, 搭配DataSnap 4等都是新功能啊, 而且DBX4 64位元也在開發之中, 上次我看到Steve present他未來準備做的DBX功能多的令人驚訝.

Q. 謝謝李老師的回覆,這可真是一劑強心針啊!又有繼續學習DBX的動力了!
那…再煩請老師看一下這個討論串
OLEDB與ODBC的效能
是關於ADO、ODBC、DBX(2007、2009)的速度實測比較
但DBX在每一項競賽中都有顯著的落後……請問可能是什麼原因呢?

A. 修正一下你的用字, DBX沒有顯著的落後, 是慢了一點, 你可以根據那篇文章的數字計算一下.
OK, 現在我來說說為什麼, 但是由於我寫的太多因此我無法貼在回應中, 請到我的部落格文章中看看吧.

[主文開始]

回覆RURU有關ODBC, OLEDB, ADO和dbExpress的問題

我看了你說的那篇文章以及那篇文章指到的另外一篇文章,老實說我在一看到那2篇文章的開始就和我的認知有差別,在我的認知中OLEDB應該不可能比ODBC快,為什麼?這是一個故事,也是ODBC,OLEDB,ADO和dbExpress各自發展的原因,因此我們需要對於這些資料存取技術的背景有一個簡單的瞭解。

ODBC當初是MS為了在Window下提供一個共通的資料存取技術而發展出來的,目的是突破當時三大資料庫廠商Oracle,Sybase和Informix對於MS的SQL Server的圍堵,此外MS也想藉由這個共通的資料存取技術幫助MS Access擊倒Lotus和Approach,因此最早的ODBC的策略是提供一個最小公約數API,讓一個標準可以存取所有的資料庫,因此在ODBC的初期ODBC的效率很緩慢,因為除了實作技術不成熟之外,當時MS SQL Server的功能也不好,因此以SQL Server為中心思想發展出來的最小公約數ODBC在存取其他資料庫時簡直慢的不想話,這也是為什麼後來Borland發展出了BDE/IDAPI之後在功能和效率方面都比ODBC好上一大截的原因。但是當MS Server SQL逐漸成熟,ODBC的實作技術也慢慢成熟之後,以最小公約數為發展中心的ODBC因為功能最簡單,因此負荷最小,到了最後ODBC的效率是最好的資料存取之一。

OLEDB是當時MS想把COM/DCOM/COM 技術推為Windows平台的唯一技術時發展出來的,如此一來在Window平台所有的通訊,資料存取和元件都以COM/DCOM/COM 為核心,因此一度Borland也準備以COM/DCOM/COM 發展IDE,資料存取等。MS當時為了這個原因,因此有了OLEDB,但是舊的ODBC怎麼辦? 因此又發展出了ODBC和OLEDB Adapter的技術,讓ODBC也可以執行在COM/DCOM/COM 的世界,讓資料存取端認為ODBC也是OLEDB。OLEDB為什麼不會比ODBC快? 因為OLEDB功能比較多,而且OLEDB是以Ole Automation封裝傳遞的資料,負荷比ODBC大,因此ODBC應該會比較快。

至於ADO則是後來MS為MS Access,MS SQL Server特別在Windows平台發展出來的存取技術,因為當時由於Internet/Intranet的沖擊,MS的COM/DCOM/COM 不適合使用在Internet/Intranet上,因此MS逐漸準備放棄COM/DCOM/COM ,這也是OLEDB的長日將盡之日,ADO接手演出之時。ADO和ODBC不同的地方是,ADO再也不是使用最小公約數為中心,而是完全以MS的資料庫為核心,這也是為什麼當ADO推出後其他廠商並不熱衷支援ADO,我記得當時Oracle拒絕推出ADO For Oracle,MS迫不得已自己為Oracle寫了ADO驅動程式,但是又慢臭蟲又多,而Borland也決定繼續發展BDE/IDAPI,只是為ADO做簡單的封裝處理,但Delphi/BCB仍然以BDE/IDAPI為核心資料存取技術。

由於ADO不是使用最小公約數為中心,因此功能比ODBC多太多了,例如資料連結池,執行緒池,可分段存取資料,資料存取到用戶端時不是把所有記錄中的資料存取到用戶端,而是只把Key存取到用戶端,一旦當用戶端實際需要整筆資料時才藉由Key把資料存取到用戶端。因此如果只是簡單的單一用戶端存取資料測試,ADO不一定會比ODBC快,但是應該差不多,不過在實際的應用中,ADO應該是比ODBC整體效率快,但是記得ADO是為了MS的資料庫而生的,因此如果是使用ADO在其他廠商資料庫上則不一定。這是為什麼一些資料庫管理工具如果是管理多種不同的後端資料庫,那麼大多仍然是使用ODBC,為什麼? 因為簡單,因此穩定一點,所以快一點。例如Embarcadero的產品就是使用ODBC來管理後端多種資料庫。

OK,討論到這裡你應該知道ODBC,OLEDB和ADO的使用時機了。

現在回到dbExpress,dbExpress是為了跨平台發展出來的資料存取技術,不是為了特定的資料庫,也不是只為了Window 32平台。dbExpress可以執行在Win32,.NET,Win64,Linux,可以存取MS,Oracle等以及CodeGear自己的InterBase和BlackfishSQL。而dbExpress是結合跨平台和一些目前用戶端先進的資料存取概念為中心,例如dbExpress也提供連結池,執行緒池等。
  • OK,因此如果你使用dbExpress和ADO來比較存取MS的資料庫,那麼一定是ADO快一點,為什麼? 因為ADO是為了MS的資料庫而生。
  • 如果你使用dbExpress和ODBC進行單一簡單的資料存取比較,那麼ODBC快一點,因為ODBC功能少,負荷少。但是在比較多的用戶端進行比較複雜的資料處理時,dbExpress就比ODBC表現的好多了,這和ADO比ODBC是類似的。
  • 如果你想使用一種統一的資料存取技術,不管對於什麼平台,什麼資料庫都有良好的執行速度,因此當你改變資料庫時你的執行效率仍然很穩定,那麼dbExpress是王者。
  • ODBC,ADO和OLEDB已停止開發,因此如果你想使用一種仍然在開發之中而且能夠應用在未來Win64和多核心,多執行緒的世界,那麼dbExpress是比較好的解決方案。
最後新一代的dbExpress.NET很快會出來(我猜應該是在Q4或是明年Q1),接著dbExpress Win64會出來,CodeGear已經在發展未來3年的dbExpress技術,因此CodeGear會不會放棄dbExpress呢?

你是技術人員,由你來回答這個答案吧,Have Fun!
[全文完]

原文轉載自:http://gordonliwei.spaces.live.com/blog/cns!CCE1F10BD8108687!2629.entry
編輯記錄
GrandRURU 重新編輯於 2008-09-20 13:45:25, 註解 無‧
mypigbaby
高階會員


發表:11
回覆:168
積分:155
註冊:2006-07-20

發送簡訊給我
#2 引用回覆 回覆 發表時間:2008-09-22 11:34:02 IP:203.73.xxx.xxx 訂閱
豬寶寶看完後想問李維老師的是 那MS的下一代是發展什麼? ADO.NET? 還是LINQ? 再者 如果遇到沒有內建在delphi 2009的DBX4 資料庫時
該如何處理?用DBX4->ODBC這樣嗎?

PS.豬寶寶不是對李維老師講的有意見..只是心中的疑問想解決而己^^"
謝謝
GrandRURU
站務副站長


發表:240
回覆:1680
積分:1874
註冊:2005-06-21

發送簡訊給我
#3 引用回覆 回覆 發表時間:2008-09-22 13:11:33 IP:203.75.xxx.xxx 未訂閱
 我不是是李維老師,只是將李維老師所po的文轉過來而已

豬寶寶大所提的

第一點,印象中不知道是在哪裡看到……ADO的下一代會是ADO .NET

第二點,若DBX沒有提供的該DRIVER,則可以找尋協力商販售的DBX Driver來使用,DBX4 ODBC......我記得網路上有提供這樣的解決方案,但ODBC for DBX的Driver我沒有下載試用過,您可以問問有用過的同好其試用心得如何。

如果有錯,還請指正,謝謝。 ^ ^
===================引 用 mypigbaby 文 章===================
豬寶寶看完後想問李維老師的是 那MS的下一代是發展什麼? ADO.NET? 還是LINQ? 再者 如果遇到沒有內建在delphi 2009的DBX4 資料庫時
該如何處理?用DBX4->ODBC這樣嗎?

PS.豬寶寶不是對李維老師講的有意見..只是心中的疑問想解決而己^^"
謝謝
編輯記錄
GrandRURU 重新編輯於 2008-09-22 13:26:09, 註解 無‧
aftcast
站務副站長


發表:81
回覆:1485
積分:1763
註冊:2002-11-21

發送簡訊給我
#4 引用回覆 回覆 發表時間:2013-05-23 03:09:16 IP:114.44.xxx.xxx 訂閱
最近因為將可能會幫忙一家公司寫商用軟體,不得已又把過去寫db方面的東西再復習一下。我很認真的寫關於db的程式大概是2005年以前的事,之後都一直專注在系統通訊上較多。過去,我一直都選用ado來寫bcb的程式,想當然,我也用它來寫asp之類的程式,覺得ado很棒! 至少與ms的結合是很強的,效能也不錯!

直到也是約2006年左右,許多人開始放下bde,進而轉dbexpress…當時我沒很深入的去了解dbexpress。我固執的覺得ado是最能讓我在win平台上跨不同語言,連ado net一開始也是很像ado,所以我選它來寫c#,bcb,asp,php,perl…通通不用變習慣。慢慢的我接受到一些dbexpress的文章等…可能是我還是覺得「並不會比較優,除非要跨平台」。

現在又看了ruru的這篇文章,(也許我過去也看過),但這回我的感受變了…變得「更加堅強的要用ado」(別打我! :p) 因為:

1/ ado是不是真的死了? 看一下這篇吧: (也許是此一時彼一時…ms的動向也是經常會變化的,不過ado用的人太多了,你不能想像當我用vc 寫db時的痛,沒ado我真的想死)
http://msdn.microsoft.com/en-us/library/ms810810.aspx#bkmk_DepMDAC_WDACComps
可明顯的不是死了,而且也support 64bit,而且vista後mdac的driver變名,「且變成內建的系統driver]」。
2/ dbexpress,感覺…好像…自家人都快玩死自己,現在又來個anydac…(其實在2000年初不久時就有個叫zeos,我一直持續關注它,發現…原來近來說的unidac,anydac,和它是很接近的東西啦)

結論:
若不考慮跨平台應用,肯定100%選用 ado。效能、複雜度,有的沒的… dbexpress不會好到哪裡去。對了,我順便google了一下2002年borland官方的一篇講upgrade到dbexpress的文,原來…它主要是為了bde的老舊性加上當時「可能」跨平台而來。它不是來打ado之類的!
• Minimize size and system resource use.
• Maximize speed.
• Provide cross-platform support.
• Provide easier deployment.
• Make driver development easier.
• Give the developer more control over memory usage
and network traffic.

至於anydac? 也許吧…若考慮跨平台,它才是好選擇。至少我個人覺得它比dbexpress好多了(driver少,3rd要錢,版本問題,寫的複雜度也高--拉n個,效能?? 單向我沒話說,但單向應用極少)。這也和剛說的為何我2000年初一直關注zeos的理由是一樣的!

若我的應用一直都在win平台上,那麼ado換個connectstring也就換了不同的dbms了,也是極度方便。加上odbc夠多,幾乎都有,所以用oledb for odbc 這個ado provider就肯定搞定! 若是mssql,那就 native client 這個provider。

你說??? 幹嘛dbexpress?

原諒我這麼晚才回/寫這篇文,因為我近日才開始認真的要再寫一個比較大一點點的商用軟體! XD

PS, 也應對到近來有不少人問db的使用時機,datasnap,有的沒的… 「我覺得有許多的東西是叫好不叫座的」,datasnap? 個人覺得不會是「普遍性 」應用的範圍!
------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan
編輯記錄
aftcast 重新編輯於 2013-05-23 03:15:13, 註解 無‧
aftcast 重新編輯於 2013-05-23 03:17:02, 註解 無‧
aftcast 重新編輯於 2013-05-23 03:20:25, 註解 無‧
aftcast 重新編輯於 2013-05-23 03:23:10, 註解 無‧
aftcast 重新編輯於 2013-05-23 03:30:23, 註解 無‧
P.D.
版主


發表:603
回覆:4038
積分:3874
註冊:2006-10-31

發送簡訊給我
#5 引用回覆 回覆 發表時間:2013-05-23 10:13:03 IP:118.169.xxx.xxx 未訂閱
看了以上的討論, 反而更令人啟疑竇, 目前看到 XE2以後的版本 非常強調  datasnap 的技術, 
而在上次的研討會, 李維也提到未來要跨平台, odbc, bde, ado, dbexpress, 都不太適用,
在更早, 我好像有印象, 也是研討論提到, datasnap 的核心還是用 dbxepress 在驅動,
因為我們以前的Delphi頂多是用到 ado 寫 client-server架構就已經算是不錯的了, 所以對後面發展的結構
說真的, 接觸的很少, 甚至完全沒有使用過, 再來 xe4 發展 firedac, 我沒有看過這方面的技術,
那今天使用 xe4 發展 win 的平台, 是否還能使用 datasanp 來發展n-tier, 跨平台 datasanp使的上力嗎?
而 firedac 又是怎麼的發展技術, 有可以參考的嗎?

是否EMBD 相關的推廣應該在這方面要整合並提供更明確及充足的資訊, 要不然 用XE4 寫程式,
等CODE都出來, 才發現所使用的資料庫架構竟然是一條死胡同, 到時又是死一地, 這對好不容易
起來的XE4(5,6,7,8,9...)聲勢, 將會是最殘忍的打擊~!!
但是也不要叫我直接上EMBD上去看所有的知識, 我們都是有身負重任的開發, 實在沒有那麼多時間可以
一篇篇來翻譯了解, 等全部搜尋完畢, 我們大概也不用寫程式了, 所以既然XE4都已引起了熱烈的回響
(至少相較於以往的反應), 我認為這股氣勢能如何持續, EMBD的態度是十分重要的! 但很可惜的是,
我目前所看到的 EMBD還是著力於IOS這塊市場的特異功能在主打, 上週我才看到一則新聞, 目前
GOOGLE的陣營雖然在市佔率仍輸APPLE, 但在平台的使用率早已超越APPLE, 所以 IOS出來(就目前)
那已經不是一個大家所熱列期待的事情, 或許在美國本土還是略勝一籌, 但跨出美國本土呢? 還能有多少勝算?
如果這是在兩年前就已經具備的, 那真的是讓人驚豔的一個技術~

再者, 就像在XE3曾發表過一款資料庫(原諒我已經忘了什麼名字, 好像叫 BLACK... 是接近於INTERBASE方面的),
目前也完全沒有再聽提起過, 那這個跨平台可用否? 其實只要找到一個跨平台可用, N-TIER可用的,
何妨EMBD提供完整的技術支援要如何發展, 那怎麼會沒有人會傾心呢?
其實我不想了解前世今生, 前世的我來不及參與, 今生的已經錯過, 我只看未來, 那才是生存之道!
編輯記錄
P.D. 重新編輯於 2013-05-23 10:14:27, 註解 無‧
P.D. 重新編輯於 2013-05-23 10:23:37, 註解 無‧
系統時間:2024-03-29 6:42:40
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!