Firebird一款很牛X的數據庫

Borland InterBase和開源的FireBird是一個強大的、支持SQL語言的數據庫, 她常常用於嵌入式開發和特定的應用軟件中。聰明的開發者和架構師花些時間詳細的瞭解下IB/FB就會發現，她確實有多處超越MSSQLserver的優點。這些優點包括： 在混合讀寫環境下更加卓越的併發性； 更靈活的觸發器支持； 更快的災難恢復； 更簡單的事件管理； 更多的部署選擇； 跨平臺支持； 小巧； 系統要求更低； 更短的培訓時間； 更低的培訓費用； 更低的許可費用；(FireBird徹底免費)

本文將詳細討論這些優點。 今天的嵌入式和分佈式數據庫應用創造了一種環境——由短期的讀事務和更新事務 (典型的如數據錄入系統)以及長時間讀事務(如製做報表和數據分析)這兩種狀況組成。當數據分析要求立刻在此刻獲得一個一致的數據視圖時，MSSQLServer必須加鎖來防止其餘用戶存取正在分析的數據。 IB/FB的數據庫引擎專門設計成可以及時的爲你的數據提供一個一致的快照，而不會阻塞其餘用戶的讀和更新。在IB/FB中，讀操做毫不會阻塞寫操做，寫操做只有當兩個事務試圖在同一時刻更新同一行時阻塞寫操做。另外，IB /FB的併發模型是徹底可預測的。使用IB/FB，毫不會有MSSQLServer裏相似鎖的任意升級致使整個表的存取被拒絕麻煩。 IB/FB 擁有嵌入式或須要遠程部署的應用所須要的全部關鍵特性。 你的開發團隊很容易學習和使用，很容易部署且在產品中幾乎不須要維護。IB只有只有MSSQLServer最小安裝大小的六分之一(FB更小)，卻提供了 SMP支持，跨平臺支持，先進的基於成本的查詢優化，行級鎖，從服務器災難中即時恢復，事務支持在任什麼時候刻及時提供一致快照的隔離級別，豐富的SQL方言，before和after兩種觸發器，完整的觸發器觸發順序控制，存儲過程，在線備份，在線修改元數據，複製，以及在客戶端的應用程序中觸發來自數據庫觸發器的事件。 IB在三方面下降項目中的成本： 一、IB的受權許可費用比MSSQLServer低(FB是徹底免費開源的)； 二、須要更少的時間培訓。一個MSSQLServer2000的DBA認證至少須要22天的課堂培訓。 IB/FB學起來是如此容易以致於其培訓課程只需5天，就可使一個徹底的數據庫新手達到可以爲IB/FB數據庫提供信賴支持的程度。那些已經對基本的數據庫管理熟悉的人會發現，不時查詢一下Interbase的文檔就是所須要的一切了。 三、開發人員沒必要花時間尋找創造性的方法來寫代碼解決數據庫的限制， 好比鎖衝突，鎖升級，缺乏的"before"觸發器，有限的觸發器觸發順序控制和須要的事件。

爲你的項目選擇合適的數據庫 建一個你的數據庫項目須要的屬性列表不是難事。 但僅依靠一個簡單的特性列表來評估數據庫是不夠的。爲你的應用程序選擇一個正確的數據庫時最關鍵的一步是調查在你的應用程序將會遇到的真實情形中，你所考慮的數據庫的行爲。本文調查了IB和MSSQLServer在許多狀況下的行爲，在當今的商業環境中你頗有可能面對這些狀況。

數據的一致性與併發性 假設你有一個存貨管理系統，用於跟蹤許多倉庫中的產品條目。 在系統運行時，你的應用程序必需要出一個存貨估價報表。使用讀提交(read committed)的事務隔離，會發生下面的一系列事件： 一、開始一個將要合計價值的讀事務，從各個倉庫收集條目； 二、這個讀事務掃描Abilene倉庫的全部記錄； 三、另外一個用戶開始一個更新事物，從Abilene倉庫移動1000金條到San Antonio倉庫； 四、更新事務提交； 五、讀事務讀到San Antonio倉庫的記錄。這個讀事務如今就把1000金條計算了兩次， 一次在Abilene倉庫，另外一次在San Antonio倉庫。 在 MSSQLServer中，經過給讀事務使用Serializable(連續讀)事務隔離很容易避免這個問題。 Serializable隔離模式保護你的事務在其生存期內不會看到由其餘用戶做出的改變。然而，要達到這種效果，MSSQLServer要麼鎖住整個表，要麼在WHERE語句跨越的全部覆蓋值的索引上放一系列鎖 (引自Microsoft SQL Server 2000, Microsoft Press,799頁)。 雖然這些鎖比表鎖限制少，但仍有不少原本沒必要要的行被禁止插入。考慮下面的SELECT語句： SELECT * FROM CUSTOMER WHERE CITY >= 'Charleston' AND CITY <= 'Los Alamos' 假設在CITY列的索引中覆蓋的WHERE語句的範圍是Abilene, Detroit, and San Francisco這些節點，那麼這些節點都會被鎖住。不幸的是，這將意味着你不能插入這樣一列，它的值大於Abilene而小於Charleston，即便WHERE語句沒有包含這一行，由於它在鎖的覆蓋範圍內。一樣的緣由，你也不能插入其值大於Los Alamos而小於San Francisco的行(引自Microsoft SQL Server 2000, Microsoft Press,776頁 )。 雖然數據的一致性達到了，但這也犧牲了併發性， 由於其餘用戶不能在行鎖覆蓋的行及表鎖覆蓋的表上插入和更新的記錄。當分析和彙總大量的數據時 ——好比上面的例子，在讀事務結束以前，其餘用戶的插入和更新會一直被阻塞。 在IB/FB中，因爲IB的版本引擎機制，這個問題根本就不存在。回到庫存估價的例子中，下面是IB/FB的狀況： 一、使用快照事務隔離機制，讀事務開始； 二、讀事務掃描Abilene倉庫的記錄； 三、另外一個用戶開始一個更新事務，從Abilene移動1000金條到San Francisco； 四、更新事務發現一個更早的活動事務，因而爲須要更新的記錄建立新的版本； 五、更新事務提交； 六、讀事務讀到San Antonio中更新的記錄。 讀事務看到當前記錄的版本是由一個在它以後開始的事務建立的，因而它往回掃描記錄的版本，直到它發現一個在它開始時已經提交的版本，並讀那個版本。 經過讀那些只在讀事務開始時已經提交的記錄版本， 不用禁止記錄的更新，IB/FB就能提供一個邏輯上一致的數據視圖。

死鎖 假如用戶A執行一個SELECT語句讀Parts表中的全部行。用戶B也SELECT了Parts表的全部行。兩個用戶都要得到各自所選數據的一個穩定一致的視圖。用戶A試圖更新part=100的記錄。用戶B試圖更新part=101的記錄。 MSSQLServer 會使用重複讀或serializable事務隔離，這種狀況將致使死鎖，即便兩個用戶更新的是不一樣的行。怎麼會呢？A在讀記錄時獲得表上的一個共享鎖。B 也同樣。當A更新part=100的記錄時，必須獲得這一行的排他鎖，因而把他在表上的共享鎖轉換成意向排他鎖。然而，意向排他鎖和B的共享鎖衝突，因此沒法獲得(引自Microsoft SQL Server 2000, Microsoft Press,799頁 )。一樣，當B要更新part=101的記錄時，由於A的共享鎖，B也不能把他在表上的共享鎖轉換成意向排他鎖。這就是所謂的轉換死鎖(見 Microsoft SQL Server 2000, Microsoft Press,776頁 )。 在IB/FB中不會發生鎖轉換。IB /FB只會在更新時鎖住個別的行。IB/FB只會發生一種類型的死鎖就是循環死鎖(全部數據庫都存在），也就是當用戶A更新並鎖住了行100，而後試圖更新已經被用戶B加鎖並更新的行200，同時，用戶B也試圖更新已經被A加鎖的行100。這種狀況下，會發生下面兩種狀況之一。若是有用戶在他們事務中指定了NoWait選項，那麼當A試圖給B已經鎖住的行加鎖時，會當即返回錯誤信息，反之亦然。若是兩個用戶都選擇了等待加鎖的行，那麼鎖管理器將檢測到死鎖並選擇一個事務讓其回滾。

鎖衝突 考慮這樣一種情形，當用戶A對一行進行了更新操做但沒有提交事務，而後A去吃午餐了。用戶B執行一個包含此加鎖行的SELECT操做。 使用MSSQLServer，用戶B的事務將一直等待，直到用戶A持有的鎖釋放爲止(MSDN-Locking Architcture at http://msdn.microsoft.com/librar ... c/8_ar_sa2_2sit.asp )。「缺省設置下，沒有強制超時期，也沒有辦法在加鎖以前測試出釋放的資源是否被鎖，除非企圖存取數據(潛在獲得不肯定的阻塞)」(見Microsoft SQL Server 2000 Books Online, LOCK_TIMEOUT Setting)。「爲了預防這種不肯定的等待，須要設置鎖的超時期，使用SET LOCK_TIMEOUT命令，但這個設置會影響鏈接中全部事務」(見Microsoft SQL Server 2000 Books Online, SET LOCK_TIMEOUT)。 IB/FB限制更少且更靈活。使用快照事務隔離(snapshot)，你一直讀的是事務開始時已經提交的行的最新版本。使用讀提交(read committed)事務隔離，IB/FB給你三種選擇： 一、讀這一行最新提交的版本即便有未提交的版本存在； 二、等待，直到未提交的版本也提交或回滾，而後讀這一行； 三、當即接收到一個異常警告：存在此行的一個未提交版本； 這些設置在事務級別，所以同一鏈接中，你爲某一個事務的所做的設置不會限制到你爲其餘事務的所做的選擇。 鎖升級 設想你正在開發一個訂單錄入系統。訂單條目表會包含上百萬條記錄。你必須可以經過客戶類型和銷售地域中的條目爲某一時期生成銷售報表，報表必須基於一致的數據視圖。生成年報表將在訂單條目表中選擇超過百萬的記錄。 「當一個事務超過升級上限時， MSSQLServer2000會自動升級行鎖和頁鎖。好比，當一個事務須要表中的一些行時， SQLServer自動得到這些行的鎖，並在包含那些行的頁、表或索引上放置更高級別的意向鎖。當事務持有的鎖的數量超過其極限時，SQLServer會企圖把表上的意向鎖變爲更強的鎖(如意向排他鎖轉爲排他鎖).得到更強的鎖後，全部此事務持有的頁級和行級鎖被釋放，鎖開銷減小了。」(見http://msdn.microsoft.com/librar ... c_8_con_7a_5ovi.asp, Lock Escalation )鎖升級的結果是整個表對其餘用戶再也不可用。在本例中，記錄上的共享鎖將升級爲一個表上的共享鎖。因而其餘全部用戶都不能更新此表中的任一行。若是要更新一個表中的大量行，那麼更新須要的排他鎖可能升級爲表級鎖，以防止其餘用戶讀和更新這張表。 IB/FB的版本體系結構在讀記錄時不須要任何鎖。經過記錄的不一樣版本，一致性的數據視圖不須要放置鎖，更不會阻塞其餘更新操做。IB/FB的鎖只是行級別的，且只在更新一行時存在，因此根本不存在鎖升級的概念。

觸發器的靈活性 當給數據庫添加新客戶時，系統必須自動指定其銷售區域和銷售表明。爲了指定正確的銷售區域，應用程序必須從State表中查找用戶所在的州，而後用銷售區域和客戶的分類代碼查找Sales Rep表。理想的解決方案是給Customer表添加一個Before Insert觸發器， 在記錄插入Customer表以前添加銷售區域和銷售表明號碼。 MSSQLServer沒有在事件以前激活的觸發器，只能附在 INSERT,UPDATE或DELETE事件以後激活(見Microsoft SQL Server 2000, Microsoft Press,657頁)。 爲了解決上面提到的問題，可使用所謂instead-of觸發器。這種觸發器激活後取代它所附屬的事件。在本例中，將激活這種觸發器，但那條新的客戶記錄不會被插入到數據庫中。所以，觸發器不只要決定銷售區域和銷售表明，還要執行把新客戶記錄插入數據庫中的INSERT語句。這使得觸發器很複雜，時間也浪費在寫觸發器上了。 更不幸的是，instead-of觸發器還有其餘限制。每一個事件只能有一個instead-of觸發器。不能用多個觸發器來模塊化你的代碼，以便容易維護。Instead-of觸發器也不能和某些外鍵一塊兒使用——這些外鍵給觸發器所依附的事件設置了級聯選項。好比，若是某個表有一個設置了級聯刪除的外鍵，instead-of觸發器就不能出如今這個刪除事件中。 IB/FB給INSERT,UPDATE和DELETE同時提供了before與after觸發器。每一事件的觸發器數量沒有限制，在觸發器和外鍵約束之間也沒有任何衝突。 同一事件的多個觸發器能使代碼模塊化，便於測試和維護。然而，對於觸發器執行的順序，MSSqlServer只提供了頗有限的控制。你能指定某一觸發器第一個觸發或最後一個觸發，但僅此而已。一旦觸發器必須獨立於觸發順序，那麼它們寫起來很複雜且不夠靈活。 IB/FB能夠制定觸發器執行的精確順序。在觸發順序的任一點，隨時可以很容易的插入新的觸發器。 對於MSSqlServer來講控制觸發器中的錯誤很難。一旦觸發器在事件以後觸發，撤銷觸發器執行的INSERT,UPDATE或DELETE操做的惟一方法就是回滾事務。因爲一個致命錯誤或請求回滾事務，觸發器內的回滾停止了整批SQL指令，而不只僅是那些由觸發器作的修改(見Microsoft SQL Server 2000, Microsoft Press,687頁)。 IB/FB中，若before觸發器產生異常，以前發生 INSERT,UPDATE或DELETE將會停止。IB/FB也容許在觸發器激活時建立指定的還原點(savepoint)。你能夠隨時回滾到任一還原點。好比，更新前(before)觸發器中建立一個還原點，而後在更新後(after)觸發器中回滾到這個還原點，從而使該還原點後的所作的修改(包括觸發此觸發器的UPDATE自己)撤銷了。不僅是在存儲過程和觸發器中，還原點在事務的任什麼時候候均可用。

成本 應用軟件也許分佈在許多地方或支持許多用戶，當使用到數據庫時，數據庫自己的許可費用會變爲項目開支的一個重要部分。下面的表格比較了IB與MSSQLServer2000標準版的費用。IB在每一類中都更加實惠。 (注：由IB開源而來的FB是徹底免費且源代碼公開的，即便在商業用途中，也是如此) 用戶數 CPU個數 Borland InterBase MSSQLserver2000標準版 20 1 2300美圓(下同) 4498美圓(下同) 20 2 3300 4498 50 1 3700 4999 50 2 4700 9998 50 4 6700 11245 100或200 1 4199 4999 100或200 2 5199 9998 100或200 4 7199 19996

資源需求 減小部署費用的一個方法是經過網絡發佈你的應用軟件。另外，你也許一樣但願能減小部署地點的硬件升級所需的開支。 MSSQLServer2000須要「97到270兆的可用硬盤空間，典型安裝須要250兆」。Windows2000下須要64兆內存，WindowsXP下須要128兆內存。(見http://www.microsoft.com/sql/evaluation/sysreqs/2000/default.asp) IB徹底安裝須要不到40兆的硬盤空間。若是你不安裝文檔和例子，那麼安裝少於15兆（FB所需更少）。此外在全部平臺下，運行IB只須要32兆的內存。

部署與發佈 你或許想把數據庫服務器和客戶端的安裝集成到應用軟件裏，使安裝部署更容易。 但你必須使用Microsoft提供的安裝包來安裝MSSQLServer。「SQLServer的安裝程序寫註冊表，改變系統路徑和多處系統設置，建立程序組和用戶帳戶，併爲其使用執行基本的初始化配置。安裝程序遠非僅僅拷貝文件。對於你來講，做爲服務或產品的一部分建立本身的程序來安裝 SQLServer是不現實的(見Microsoft SQL Server 2000, Microsoft Press,166-167頁)。」 與之相比，IB/FB給了你徹底的靈活性。你可使用自己的安裝包，也能夠用其餘安裝打包軟件，或者乾脆本身寫安裝程序。

MSDE 也許，做爲使用MSSQLServer的另外一種選擇，你會考慮使用MSDE來部署發佈應用程序。 MSDE就是SQLServe2000，擁有其全部特性和限制。MSDE還有三個額外的限制。「爲了達到最佳性能，有一個限制在五個併發工做量的併發量管理器」， 「若超過五工做量的限制，併發管理器會使系統不斷的慢下來」(見http://www.microsoft.com/sql/msde/productinfo/features.asp)。每一條工做量是一個鏈接，若是每個用戶須要兩個鏈接，那麼MSDE就只能支持兩個用戶。MSDE須要44兆的硬盤空間，2000下64兆內存，XP下128內存。(見http://www.microsoft.com/sql/evaluation/sysreqs/2000/default.asp) 「MSDE支持2G如下的單個數據庫。」——注意不是每一個表。這是第二個額外限制。這也就是說你的全部數據，元數據，索引，臨時表，存儲過程和觸發器加一塊兒必須在2G之內。 「MSDE2000包括一些供管理實例的命令」(見http://www.microsoft.com/sql/msde/productinfo/features.asp) ——MSDE不提供任何MSSQLServer的GUI工具來設計和建立數據庫，管理服務器，測試查詢和調整服務器的性能。 「幾個Microsoft的產品有權許可轉讓使用和從新發布MSDE2000」(見http://www.microsoft.com/sql/msde/productinfo/features.asp) 得到的這些權力很複雜，並且依賴你購買的得到MSDE2000的Microsoft產品。有些產品不包括從新發布的權力。其餘能從新發布的須要知足多方面的條件。

特性 下面的表格比較了IB/FB和SQLServer的特性。這個表單並不徹底，可是集中了重要的特性，如遠程部署的嵌入式應用、長時間讀事務間雜着更新事務組成的應用。 特性 InterBase/FireBird SQL Server 事務支持 是 是 SQL支持 是 是 用戶自定義函數 是 是 基於成本優化 是 是 提供不會阻塞更新的一致數據快照 是 否 行級鎖 是 是 不存在鎖升級 是 否 不存在轉換死鎖 是 否 快照事務隔離 是 是 兩段式提交 是 是 支持多用戶和單用戶 是 是 支持SMP 是 是 存儲過程 是 是 before觸發器 是 否 after觸發器 是 是 觸發器觸發順序控制 是 否 觸發客戶端事件 是 否 自動生成鍵 是 是 支持全部數據類型取空值 是 是 參照完整性 是 是 在線備份 是 是 在線更改元數據 是 是 複製 是 是 即時災難恢復 是 否 零維護 是 是 定製安裝包 是 否 內存須要 32MB 2000下64MB，XP下128MB 硬盤空間 40MB(包括文檔和例子)，不然不到15MB 平均250MB

結論 IB/FB是你擁有： 混合讀寫環境中卓越的併發性； 更靈活的觸發器支持； 更快的災難恢復； 更容易的事件管理； 更多的部署選擇； 跨平臺支持； 小巧； 系統要求更低； 更短的培訓時間； 更低的培訓費用； 更實惠的許可費用... IB/FB以最低的成本和最短的時間，提供了建立強大應用所須要的特性。

做者簡介：Bill Todd是Database Group, Inc.(Phoenix旁邊的一個數據庫諮詢與開發公司)的總裁。合著過4本數據庫編程方面的書籍，發表超過100篇文章。在美國和歐洲的開發者大會上提交了超過20篇論文。