天天看點

ODBC與BDE

*2004年左右寫的資料,在這裡留個底! 

ODBC與BDE是兩種不同的資料庫引擎!前者為MicroSoft內建到Windows中,後者為Borland公司随同其開發工具(Delphi,Cbuilder,Kylix)安裝的。ODBC其意義為開放式資料鍊路(大緻如此),BDE為Borland Database Engine的縮寫,意為Borland資料庫引擎。BDE相對ODBC而言沒有任何優勢,且已成為落日黃花,其已停止更新。而ODBC也并非就此一統天下,随着各種不同開發工具的出現,為了大家間可以通過一種标準協定而通路不同的資料庫,先後出現了DAO,OLE

DB,ADO等.其前還有MicroSoft專為VB設計的MS JET,最新的為适應網絡傳送及更大範圍内的相容而開發出的XML(确切的講它應當是一種标簽代碼).總之不同資料庫引擎都是為了讓應用程式以統一的形式通路資料庫,而無論資料庫的組織形式如何.

ADO的應用相對于其它DE而言是較為廣泛的,其為MicroSoft開發的,存在于Windows系統中(較早系統需安裝Ado Pack   Pack為Package縮寫,即為更新檔).Delphi自5.0開發支援ADO,ADO在效率上高于ODBC及BDE,且更為穩定,其主要基于OLE(Object Linked-Emmbed! 對象的連結與嵌入  在Word中插入Excel表并視同在Excel中編輯就是這一技術的典型應用.此後逐漸發展為DCOM及COM+的分布式應用).

ADO在Delphi的使用主要集中于幾個ADO控件.在Delphi控件面闆上有一ADO項,其下主要包括ADOConnection,ADODataSet,ADOQuery,ADOTable,ADOStoreProcedure,ADOCommand等控件,如果去除前面的ADO一詞,同Data Access中的控件是相似的.其實Borland在引入ADO時就已考慮如何讓使用DataBase,Query等BDE控件的程式員快速掌握ADO開發(而不是原始ADO,Delphi中的ADO是經過封裝的ADO,當然在效率上是有一定的損耗的,相對易用性還是值得的).在幾個控件中ADOCommand是效率最高的一個!

在ADO中主要是ADOConnection取代了DataBase的功能,而其中也包括了ODBC及OLDEB等..在窗體上放置一ADOConnection并輕按兩下之,在下圖中:

ODBC與BDE

點選Build.Show出如下窗體:

ODBC與BDE

其中各項不必都要了解.如果使用SQL Server可以直接使用圖中所選一項.

ODBC與BDE

標明Server名,設定使用者及密碼,選擇使用的資料庫就可以完成設定了.

ADO也可以通路ODBC的.注意一點ADO與ODBC的基理并不相同,兩者在底層實作是有天壤之别的.ADO對大資料流的支援是極佳的.

在資料庫程式設計時,盡量減少同Server通訊時間,特别是取資料及寫資料的時間,最好使用一批一批送出的方式,而非一筆一筆的送出.這一點可以使用Datase.Post,及ADOConnection.BeginTrans及ADOConnection.CommitTrans實作.在Query設定CachedUpdates屬性設為True.

ADO的用性較Data Access中控件還有許多的特殊之處,但要完成的操作是相同,隻是實作方式不同.如果單純在程式員的角度上考慮就不需要了解系統如何完成的操作,隻要理清我們要完成什麼操作.

資料庫操作主要是一.控制類的   建表建庫,删表删庫,修改表體中欄位資訊(包括删除,修改及插入). 二.操作類的   取(寫)記錄,修改,删除及插入記錄.查找,條件查詢類(就是一般的語句加一個Where),簡單的資料運算(彙總Sum,求均Avg等)沒了,調用存儲過程(就跟寫一條查詢語句一樣,并且還要簡單). 在前端就是這些了.餘下就是将資料庫好好包裝一下,加入View,Trigger(觸發器),StoreProcedure之類的控件.寫一個存儲過程的功能就要考量Cursor(遊标)的應用.我們在編寫資料庫程式時常常會有一個效率的問題,如何讓資料處理更為快速.(如何穩定是算法設計上的問題)在這一點上,很多人都忽略了資料庫本身強大的資料處理功能,如果有一種應用程式可以将資料處理的功能做的很好,那它就可以是一種資料庫伺服器.無論SQL

Server還是Oracle都內建了強大的資料處理功能.甚至是各種API可供程式員自行編寫低階的代碼,以提高伺服器的應用.是以我們有理由相信資料庫已經為我們設計了整套的解決方案,我們完全可以将更多的工作交給資料庫完成.

我來介紹幾個典型應用,A公司的人考以前處理考勤及薪資有時處理一天以上,可能都沒有結果,而另一家B公司卻可快速的處理,三千多人的薪資資料不到5分鐘就可以完成,其中就是前者使用前端計算,一筆筆送出,後者采用存儲過程計算.以三千人而言,前者的流程是取出資料,計算這個人本月資料,然後寫入資料庫.不計計算時間(計算時還要取資料),就要和資料庫通訊至少至少3000*2次,而後者隻是調用存儲過程,加入一些參數,将由此組成的語句傳給資料庫就好,通訊次數一次.一般系統的限制點都在I/O上,而僅此就有6000倍的差距.

原因就在于對資料庫的應用上.

在A寫資料庫程式時,總有一點,我們需要在送出時(Query的BeforePost事件中)對一些相關資料做處理.比如送出一個人的請假單時,我們要同時将統計人數加一.我們要一個人做離職處理時,也即删除這人記錄時,需要同時删除這個人的其他相關資料(比如出勤,保險等).另一類可能較多出現,就是某人的工号或卡号更改了,如果表體組織的不好就要在多個表中做改号的工作.類似這樣的操作我們都可以使用Trigger完成,進而省去了在前端先判斷,再處理過程,首先省去了大量的可能也是重複的處理動作,也同時降低了I/O成本.

另一應用是有關開表的.表體的組織越符合範式越好.這一點我十分認同.一般我們做到二級範式2NR就可以了,可以省去不少麻煩,不至于時常在兩表間處理,也兼顧了效率.上面所提人員改号一事都是這一點的正面例證.我們需要将表體組織的簡潔高效,就要争取符合較進階的範式.但并沒人限制我們表體數目,資料的存儲隻要不是備援,就符合要求.同樣假設存在這樣一個需求(可能較少出現),我們在經常需要查詢一些人數或彙總之類的統計資料,如何單開一表,并加入合适的Triger處理以保證資料的有效性,如此這般,我們便不用周而複始的做彙總統計.這隻一方面,在許多情況資料庫的有效組織将為程式的開發大開友善之門,并能有效提高系統的健壯性,穩定性及高效的要求,減少前端處理操作,真正實作瘦用戶端的要求(Thin-Client).雖然計算的運算速度不斷提高,但其要處理的資料也将越來越多.

是以,在軟體公司中應設立資料庫專職程式員,以緻力資料庫的優化.

另外我簡要提一下開發文檔.開發文檔作為系統開發過程記錄,是日後系統更新及技術支援的重要資料.是以一定做好開發記錄,比如年月日,完成(修正)了什麼功能,什麼方式,代碼所在單元.寫代碼時要盡量加入充足的注釋,按CMMI2的要求不應少于1/4,其實這也沒有必要,隻要充足,可以表時下面代碼的意義就可以了.

最後我再提一下PSP及TSP.軟體開發作為一種産業,正漸變為一種流水線式的生産,大項目的導入,流程監管都有詳細的規範.這其中最基本的就是PSP及TSP.PSP Personal Software Plan(也有另一種提法),它是指個人軟體計劃.是軟體工程師自身提高的一環,它主要是一種表格,表明你的工作排程.如什麼時候完成什麼工作,分為幾個步驟,各步驟實作目标及預計時間.當完成各步驟時填入實際完成時間.

TSP Team Software Plan.小組軟體計劃.  小組協作是一個項目成功的關鍵.一個開發小組涉及的人員都要有良好的協作精神.這一點如果展現在工作是就是多溝通,多交流.(在規模稍大一點的公司,這一含義就更為嚴苛了,或者說是一種制度).

以上都是一些概念性的東西.心裡有底就好.

後面所提文檔及TSP,PSP都是軟體工程的一部分.軟體工程是門重要的學問,非常有必要研究應用.

繼續閱讀