專刊內文

當前位置:首頁>專刊分享>內文

瀏覽次數 : 8021



 

資料庫開發過去與未來

訊光科技 / Andy Kao

 

前言

應用軟體的開發演進大約至少30多年了,30年可是一個漫長的過程,即使科技的進步神速,但對於商用軟體來說好像並不是這麼一回事;當然如果以資料庫來說,或許因為SQL的興起,讓應用軟體可以容納更多的資料與得到更快的回應速度,且讓資料的儲存穩定度也提升了不少;但如果是針對開發工具或開發語言來說,就很難斷言科技所帶來的是極大的便利與效能,畢竟20年前在DOS或Terminal時代開發效能也不一定比現在慢,為何會如此呢?主要是因為這20年來的作業系統變化很大,從文字模式到了圖形模式,又從圖形模式轉向網路與3D的介面,這個轉變,會讓整個應用軟體的開發模式發生了很大的變化,程式因為介面變得很複雜,因為觸發的事件處理,變得很容易出問題,當然,科技的進步是必要的,開發的模式與方法也是必須配合更新與提昇,只是事過境遷,總覺得過程中有過多的資源浪費與走過的冤枉路,對於開發的相關業者造成過多成本的浪費與經營的風險,確實是值得深思的話題。


資料庫的演變



如圖,我們可以從商用軟體的開發歷史,來了解整個演變的過程:

1. 資料檔的時代:這個時代想必還蠻值得大家懷念的,資料庫都是自己開發自行處理,格式自由,雖然資料庫都要自行處理,但不代表很麻煩,因為不管Cobol或C所寫的系統,對於資料檔有一定的處理能力,比較大的問題在效能與穩定度上,畢竟你要自行建立索引格式與維護是很容易出現問題的;如果大家還有記憶的話,當時出現了dBase這種簡單的資料庫(資料檔方式),造就了當時商用軟體的蓬勃發展,簡易的關聯資料處理,已經讓大家樂翻天了。

2. SQL的時代:自從IBM推出了DB2之後,造就了RDBMS資料庫的風潮,從此資料庫就如同雨後春筍般風行市場,最後微軟也加入的戰局推出了MS-SQL後,將資料庫應用推向高峰,SQL型的資料庫系統幾乎是現今商用軟體的標準配備。主要還是資料庫提供快速且可靠的資料存取方案,加上ANIS-92制定的標準之後,更讓資料庫的地位屹立不搖,加上商用軟體對於資料庫過度的依賴,也讓SQL資料庫流行了20年至今還是主流的原因。

3. Entity的時代:由於近年來物件導向的風行,使得程式的開發都必須使用物件導向方式來開發,程式的架構既然如此,但反觀資料庫的架構卻不是物件導向架構,因此產生了格格不入的現象。前幾年,更有資料庫廠商提供了OODB的商品就是將資料庫與物件導向概念結合在一起,但在應用面上卻與傳統的RDBMS差距很大,讓開發者無法一時轉換過來,逐漸從市場上沒落了。後來又有人提出了O/R Mapping的觀念,將資料庫的Table以物件的方式來描述與對應,Table中取出的一筆資料,我們就稱之為Entity(一筆實體),這樣就可以維持原來傳統資料庫原有的架構不變,又能以物件導向的方式來開發程式,對於熱衷物件導向的開發者是一大福音,也成為新時代下的開發主流。


.Ne
t的資料介面演進

就拿.net來說,資料庫的介面也是慢慢演進的,如上圖,剛開始為ADO.net的方式,只是提供資料庫的連接方式,讓開發者可以直接以SQL語法來操作資料庫,並將取得的資料可以存放在DataSet中,當初的DataSet因為可以離線作業,而且可以保留狀態(如新增更改刪除的狀態),所以成為多數.net系統的開發資料庫存取的主力;後來微軟在.NET 3.0中推出了LINQ的新語法,希望能取代SQL語法。為何要取代SQL語法呢?SQL有一個嚴重的缺點,就是要到了執行時才會知道語法是否正確,命令錯誤或欄位與Table不存在都無法在程式編譯過程中事先得知,因此,LINQ就是要將Table與欄位明確定義,透過編譯器能夠事先防錯,提升品質;另一方便LINQ也希望使用一套查詢語言來面對不同的資料庫(因為各家資料庫都有些微的差異),更可以針對XML或DataSet甚至是Object內容來進行查詢,可惜的是,因為大大改變了程式開發人員的習慣,所以跟進的廠商與開發者並不是很多。

2009年微軟在.NET 3.5中推出Entity Framework,這是一個類似之前的O/R Mapping解決方案,它也將成為微軟跨越所有應用程式的資料整合技術方案,隨著VS2010與.NET 4.0的推出,Entity Framework更進展到了4.0 (跟著.NET版本走),除了提供多項重大新功能外,微軟更宣佈EF將取代LINQ to SQL的發展,成為資料庫存取的主流技術。


何謂Entity Framework

全名應該是:ADO.NET Entity Framework,是微軟以 ADO.NET 為基礎所研發出來的類似ORM架構解決方案,前文中我們說過,ORM (Object-Relational Mapping )只是一個以物件導向的方式來存取資料庫欄位的架構而已,並非一個解決方案,如原來的ADO.NET只有資料庫連線,你只能下達SQL語法後才能知道是否有這個Table與這些欄位,很容易出錯,但在ORM的架構上,Table會強迫物件化,因此你改用物件導向的語法來存取欄位,更符合現代的開發模式與容易閱讀性。

但是,ORM也只能做到物件導向架構而已,從資料庫中取得資料與資料的維護
(Insert/Delete/Update)都必須自行封裝在這個ORM的Class中,因此微軟就在.NET 3.5之後將其擴充成為"解決方案"等級,除了透過EDM(Entity Data Model)自動化定義資料模型取代需要半人工定義的ORM Class之外,更重要的是已經可以自動幫你做到資料的讀取與維護等等,不必再自行下達SQL語句。更令人振奮的是無關資料庫的類型,不管你是MS-SQL還是ORALCE或其他資料庫等等,都可以用同一套元件與程式來處理,這樣對開發者來說確實是令人感到振奮的好消息。


Entity Framework的優缺點

首先說明優點,如下:

1. 符合物件導向原則:承如上面所說的,EF改良自ORM的架構,所以將Table封裝在EDM中,因此我們可以透過物件導向的語法來存取這些Table的欄位並且可以執行這些Table抽象後的方法(如Insert/Update/Delete/Query等),這種開發模式是在編譯期可以發現錯誤或有問題的地方,不像傳統ADO開發,必須到了Runtime才發現錯誤,更符合現今的品質概念。

2. 隔離資料庫:因為開發過程中使用了Entity SQL或是LINQ,這樣可以透通在不同的資料庫間,不必因為資料庫不同,而造成程式必須改寫的命運.(當然必須配置不同的資料庫廠商所提供的Provider)。

3. 自動化的存取:因為EF已經不是一個簡單的ORM架構而已,Object Service層已經為你提供了Insert/Update/Delete的服務,當然是提供最基本的,複雜或困難的交易處理,也是要使用Entity SQL另外開發。

4. 更容易開發與維護:EDM的產生可以透過Visual Studio的工具以拖拉的方式來自動幫你產生,你可以不必自己建立,加上可以自動處理資料的SQL,會讓你開發資料庫軟體變得更輕鬆與省事。

5. 更好的效能:理論上,使用了EF架構後應該速度效能會變慢,因為多了一層EDM的轉換與分割,沒錯,但筆者說的效能,是因為他具有延遲載入的功能,如一開始的新增,你不必啟動後面的SQL去讀取資料,或是在Master/Detail間,當沒有處理到Detail時,可以不必預先去讀取Detail資料等等,針對關聯的外鍵資料(Foreign Keys)可以要使用時才去讀取等等,只要控制得宜,都會讓你具有一定的效能。

6. 更容易分層處理:早期使用ORM的架構最難的就是資料分層,在N-Tier架構上必須定義多份的Table Class,因為在N-Tier中並無法透通這些Class定義,造成開發上的困擾,但因為.NET 3.5以後的WCF (Windows Communication Foundation)支援了EF EDM的proxy class功能,讓分層的另一端也可以共用EDM內的class定義。

7. 更具未來性:目前包括WPF或Silverlight等微軟新的主流大都是以Entity為對象來呈現與操作,不再以ADO.NET的DataSet或DataTable的方式來處理,先不必說全部都轉過來,已不大可能這樣處理,但至少新開發的架構,可以使用EF來處理,另一個更好的好處就是,這麼強大的解決方案,是被放置在.NET 4.0中,你可以輕易的享受且免費使用。

因為以目前的Entity Framework架構來看,並非是完美無缺的,其缺點如下:

1. 未來性與持續性的疑慮:與LINQ類似,當微軟推出一項新的技術或方案時,並不是讓所有業者都可以放心跟進,畢竟有些時候需要一點勇氣與判斷力,當然,如果以目前Entity Framework的市場成熟度或許還不夠,但如果以技術成熟度來說,應該有一定的水準與評價,即使如此,還是有人抱著觀望的態度,畢竟現有的SQL方式還是可以用上一陣子。

2. 多層對應與批次處理的效能問題:畢竟Entity Framework須要透過EDMX來將資料實體對應到抽象的Entity上,其間都是必須面臨資料的多層存取轉換,一定沒有你自行以SQL操作來得便利與快速;相對的,如果你用大量的批次處理資料,以Entity Framework一筆一筆處理,其效能絕無法與一句SQL命令來得有效。

3. 無法100%滿足需求: Entity Framework並無法100%取代SQL語法,畢竟除了效能之外,還有一些特殊的資料處理也是Entity Framework很難或無法處理之處,因此還是有少數需求須要使用SQL的方式處理。


結語

科技發展當中,變與不變是個藝術,從歷史來看,資料庫或開發模式改變會不會大幅影響客戶的需求與滿意度?會降低軟體的開發生產力嗎?其實憑良心說真的影響有限,因為如果你知道這年頭還有人還在用DOS系統或COBOL的系統你就會了解影響真的有限,當然這樣說不一定公平,畢竟是市場的少數,主要是因為現實面的問題,試想DOS或COBOL的系統還有誰會維護,還有誰會持續開發呢?因為沒有開發者就沒有市場,就無法維護,商用系統也因為此往往不得去汰舊換新,市場的客戶很少因為UI很炫,科技很新而去更換系統,多數還是考量效能提升,開發維護容易,需求可以被擴增才會決定,因此,從Silverlight的推出不一定影響商用應用系統的革命,但如果從雲端的發展與企業系統要走向Web來看,確實是有必要的,加上Entity Framework所帶來的方便性,可以讓企業也有不同面向的思維。