資源需求
減少部署費用的一個方法是通過網絡發佈你的應用軟件。另外，你也許同樣希望能減少部署地點的硬件升級所需的開支。
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的特性。這個表單並不完全，但是集中了重要的特性，如遠程部署的嵌入式應用、長時間讀事務間雜着更新事務組成的應用。
減少部署費用的一個方法是通過網絡發佈你的應用軟件。另外，你也許同樣希望能減少部署地點的硬件升級所需的開支。
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篇論文。
設計這篇比較分析，旨在幫助開發商爲其特定要求選擇合適的數據庫。
Borland 白皮書
作者：Bill Todd 2003年九月
翻譯：樊鐳 2007年5月
Borland 白皮書
作者：Bill Todd 2003年九月
翻譯：樊鐳 2007年5月
目錄：
介紹
爲你的項目選擇合適的數據庫
數據的一致性與併發性
死鎖
鎖衝突
鎖升級
觸發器的靈活性
恢復速度
事件
培訓時間
跨平臺支持
成本
資源需求
發佈與部署
特性
結論
介紹
爲你的項目選擇合適的數據庫
數據的一致性與併發性
死鎖
鎖衝突
鎖升級
觸發器的靈活性
恢復速度
事件
培訓時間
跨平臺支持
成本
資源需求
發佈與部署
特性
結論
介紹
Borland InterBase和開源的FireBird是一個強大的、支持SQL語言的數據庫, 她經常用於嵌入式開發和特定的應用軟件中。聰明的開發者和架構師花些時間詳細的瞭解下IB/FB就會發現，她確實有多處超越MSSQLserver的優勢。這些優勢包括：
在混合讀寫環境下更加卓越的併發性；
更靈活的觸發器支持；
更快的災難恢復；
更簡單的事件管理；
更多的部署選擇；
跨平臺支持；
小巧；
系統要求更低；
更短的培訓時間；
更低的培訓費用；
更低的許可費用；(FireBird完全免費)
本文將詳細討論這些優勢。
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在三方面降低項目中的成本：
1、IB的授權許可費用比MSSQLServer低(FB是完全免費開源的)；
2、需要更少的時間培訓。一個MSSQLServer2000的DBA認證至少需要22天的課堂培訓。 IB/FB學起來是如此容易以至於其培訓課程只需5天，就可以使一個完全的數據庫新手達到能夠爲IB/FB數據庫提供信賴支持的程度。那些已經對基本的數據庫管理熟悉的人會發現，不時查詢一下Interbase的文檔就是所需要的一切了。
3、開發人員不必花時間尋找創造性的方法來寫代碼解決數據庫的限制， 比如鎖衝突，鎖升級，缺少的"before"觸發器，有限的觸發器觸發順序控制和需要的事件。
爲你的項目選擇合適的數據庫
建一個你的數據庫項目需要的屬性列表不是難事。 但僅依靠一個簡單的特性列表來評估數據庫是不夠的。爲你的應用程序選擇一個正確的數據庫時最關鍵的一步是調查在你的應用程序將會遇到的真實情形中，你所考慮的數據庫的行爲。本文調查了IB和MSSQLServer在許多情況下的行爲，在當今的商業環境中你很有可能面對這些情況。
數據的一致性與併發性
假設你有一個存貨管理系統，用於跟蹤許多倉庫中的產品條目。 在系統運行時，你的應用程序必須要出一個存貨估價報表。使用讀提交(read committed)的事務隔離，會發生下面的一系列事件：
1、開始一個將要合計價值的讀事務，從各個倉庫收集條目；
2、這個讀事務掃描Abilene倉庫的所有記錄；
3、另一個用戶開始一個更新事物，從Abilene倉庫移動1000金條到San Antonio倉庫；
4、更新事務提交；
5、讀事務讀到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的情況：
1、使用快照事務隔離機制，讀事務開始；
2、讀事務掃描Abilene倉庫的記錄；
3、另一個用戶開始一個更新事務，從Abilene移動1000金條到San Francisco；
4、更新事務發現一個更早的活動事務，於是爲需要更新的記錄創建新的版本；
5、更新事務提交；
6、讀事務讀到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/library/default.asp?url=/library/en-us/architec/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給你三種選擇：
1、讀這一行最新提交的版本即使有未提交的版本存在；
2、等待，直到未提交的版本也提交或回滾，然後讀這一行；
3、立即接收到一個異常警告：存在此行的一個未提交版本；
這些設置在事務級別，因此同一連接中，你爲某一個事務的所作的設置不會限制到你爲其他事務的所作的選擇。
IB/FB的數據庫引擎專門設計成能夠及時的爲你的數據提供一個一致的快照，而不會阻塞其他用戶的讀和更新。在IB/FB中，讀操作絕不會阻塞寫操作，寫操作只有當兩個事務試圖在同一時刻更新同一行時阻塞寫操作。另外，IB/FB的併發模型是完全可預測的。使用IB/FB，絕不會有MSSQLServer裏類似鎖的任意升級導致整個表的存取被拒絕麻煩。
IB/FB擁有嵌入式或需要遠程部署的應用所需要的所有關鍵特性。 你的開發團隊很容易學習和使用，很容易部署且在產品中幾乎不需要維護。IB只有只有MSSQLServer最小安裝大小的六分之一(FB更小)，卻提供了SMP支持，跨平臺支持，先進的基於成本的查詢優化，行級鎖，從服務器災難中即時恢復，事務支持在任何時刻及時提供一致快照的隔離級別，豐富的SQL方言，before和after兩種觸發器，完整的觸發器觸發順序控制，存儲過程，在線備份，在線修改元數據，複製，以及在客戶端的應用程序中觸發來自數據庫觸發器的事件。
IB在三方面降低項目中的成本：
1、IB的授權許可費用比MSSQLServer低(FB是完全免費開源的)；
2、需要更少的時間培訓。一個MSSQLServer2000的DBA認證至少需要22天的課堂培訓。 IB/FB學起來是如此容易以至於其培訓課程只需5天，就可以使一個完全的數據庫新手達到能夠爲IB/FB數據庫提供信賴支持的程度。那些已經對基本的數據庫管理熟悉的人會發現，不時查詢一下Interbase的文檔就是所需要的一切了。
3、開發人員不必花時間尋找創造性的方法來寫代碼解決數據庫的限制， 比如鎖衝突，鎖升級，缺少的"before"觸發器，有限的觸發器觸發順序控制和需要的事件。
爲你的項目選擇合適的數據庫
建一個你的數據庫項目需要的屬性列表不是難事。 但僅依靠一個簡單的特性列表來評估數據庫是不夠的。爲你的應用程序選擇一個正確的數據庫時最關鍵的一步是調查在你的應用程序將會遇到的真實情形中，你所考慮的數據庫的行爲。本文調查了IB和MSSQLServer在許多情況下的行爲，在當今的商業環境中你很有可能面對這些情況。
數據的一致性與併發性
假設你有一個存貨管理系統，用於跟蹤許多倉庫中的產品條目。 在系統運行時，你的應用程序必須要出一個存貨估價報表。使用讀提交(read committed)的事務隔離，會發生下面的一系列事件：
1、開始一個將要合計價值的讀事務，從各個倉庫收集條目；
2、這個讀事務掃描Abilene倉庫的所有記錄；
3、另一個用戶開始一個更新事物，從Abilene倉庫移動1000金條到San Antonio倉庫；
4、更新事務提交；
5、讀事務讀到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的情況：
1、使用快照事務隔離機制，讀事務開始；
2、讀事務掃描Abilene倉庫的記錄；
3、另一個用戶開始一個更新事務，從Abilene移動1000金條到San Francisco；
4、更新事務發現一個更早的活動事務，於是爲需要更新的記錄創建新的版本；
5、更新事務提交；
6、讀事務讀到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/library/default.asp?url=/library/en-us/architec/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給你三種選擇：
1、讀這一行最新提交的版本即使有未提交的版本存在；
2、等待，直到未提交的版本也提交或回滾，然後讀這一行；
3、立即接收到一個異常警告：存在此行的一個未提交版本；
這些設置在事務級別，因此同一連接中，你爲某一個事務的所作的設置不會限制到你爲其他事務的所作的選擇。
鎖升級
設想你正在開發一個訂單錄入系統。訂單條目表會包含上百萬條記錄。你必須能夠通過客戶類型和銷售地域中的條目爲某一時期生成銷售報表，報表必須基於一致的數據視圖。生成年報表將在訂單條目表中選擇超過百萬的記錄。
“當一個事務超過升級上限時， MSSQLServer2000會自動升級行鎖和頁鎖。比如，當一個事務需要表中的一些行時， SQLServer自動獲得這些行的鎖，並在包含那些行的頁、表或索引上放置更高級別的意向鎖。當事務持有的鎖的數量超過其極限時，SQLServer會企圖把表上的意向鎖變爲更強的鎖(如意向排他鎖轉爲排他鎖).獲得更強的鎖後，所有此事務持有的頁級和行級鎖被釋放，鎖開銷減少了。”(見http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_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本身)撤銷了。不只是在存儲過程和觸發器中，還原點在事務的任何時候都可用。
恢復速度
由於一次電源故障，你在達拉斯辦事處的數據庫服務器崩潰了。服務器重啓時數據庫必須自動迅速的恢復到一致狀態。
MSSQLServer重啓時恢復所需要的時間依靠檢查點(checkpoint)，因爲事務日誌必須回滾最後一個檢查點之後的所有活動的事務。檢查點由DBA週期性的創建。恢復一般需要幾分鐘，也許更長，這依賴於DBA在檢查點創建的頻率和隨之而來的性能降低之間所作的權衡 (見Microsoft SQL Server 2000, Microsoft Press,953頁)。
IB/FB在重啓時能立即恢復，因爲回滾活動的事務不需要特定的處理。IB/FB只需簡單的把每一標記爲“活動”的事務全部標記爲“回滾”即可。版本引擎會自動忽略這些記錄版本，通過垃圾收集，這些版本被移除——和數據庫正常運行時一樣。
事件
你的訂單錄入程序添加一條訂單時，相應的存貨必須減少。如果目前的存貨量降到了訂貨點，就需要通知存貨控制程序(運行在其他電腦上)。
使用MSSQLserver，必須寫一個COM對象操縱與存貨控制程序之間的通信，然後用存儲過程加載並調用COM對象的方法。
如果使用IB/FB，只需給觸發器添加一個POST_EVENT指令。在存貨控制程序中，添加一個事件操控組件，並通過設置其屬性註冊一下需要的事件。所有通信和回調機制在IB/FB中創建。你的團隊所要寫的代碼全都是業務邏輯。順便指出，如果某個用戶在添加了一些訂單後回滾事務，也不用擔心存貨系統收到錯誤的信息。直到事務提交，IB/FB纔會激活發出的事件。
培訓時間
培訓開發團隊所需要的時間是全部成本的一項重要組成，這個時間佔用的是交付你所開發項目的時間。這也是產品複雜度的一個很好的度量。Microsoft爲MSSQLServer2000的數據庫管理員提供了認證。“此認證適於那些來自物理數據庫設計的，開發邏輯數據模型，創建物理數據庫，使用Transact-SQL創建數據服務，管理和維護數據庫，配置和管理系統安全，監控和優化數據庫，以及安裝和配置SQLserver2000的個人。(見http://www.microsoft.com/traincert/mcp/mcdba/mcdba.asp)”“作爲SQLserver2000的MCDBA，至少應該有一年SQLserver的工作經驗。(http://www.microsoft.com/traincert/mcp/mcdba/mcdba.asp)”另外，認證需要22天的課堂指導和四門考試(見http://www.microsoft.com/traincert/mcp/mcdba/requirements.asp)。SQLserver是一個複雜的產品，所以它的DBA需要額外的培訓和經驗。
IB非常容易學習和管理，其最全面的培訓課程——旨在把一個完全的數據庫新手培訓成IB可信賴的管理者——僅需要5天。那些已經對數據庫管理熟悉的人們會發現，他們不需要專門的培訓，不時地參考一下IB的文檔就是所有要求了。
跨平臺支持
和桌面PC市場不同，應用服務器市場並不統一。除了Windows，Sun也處在重要的位置，特別在Web服務器方面，同時Linux正以驚人的速度增加它的佔有率。可能有時除了Windows，你還不得不支持各種服務器平臺。
當然，MSSQLserver只能在Windows下運行。另一方面，IB/FB在Sun Solaris, Linux和Windows下都可用,現在和將來你都擁有充分的靈活性。把IB/FB數據庫遷移到其他新的平臺，只需簡單的備份和恢復即可。
IB/FB也提供了各種連接數據庫的選擇——包括ODBC,JDBC,ADO.NET,DBExpress驅動和各種Delphi、C++Builder下的原生驅動，以確保開發人員能夠使用他們最喜歡的開發工具並部署他們特定的環境。。
成本
應用軟件也許分佈在許多地方或支持許多用戶，當使用到數據庫時，數據庫本身的許可費用會變爲項目開支的一個重要部分。下面的表格比較了IB與MSSQLServer2000標準版的費用。IB在每一類中都更加實惠。 (注：由IB開源而來的FB是完全免費且源代碼公開的，即使在商業用途中，也是如此)
設想你正在開發一個訂單錄入系統。訂單條目表會包含上百萬條記錄。你必須能夠通過客戶類型和銷售地域中的條目爲某一時期生成銷售報表，報表必須基於一致的數據視圖。生成年報表將在訂單條目表中選擇超過百萬的記錄。
“當一個事務超過升級上限時， MSSQLServer2000會自動升級行鎖和頁鎖。比如，當一個事務需要表中的一些行時， SQLServer自動獲得這些行的鎖，並在包含那些行的頁、表或索引上放置更高級別的意向鎖。當事務持有的鎖的數量超過其極限時，SQLServer會企圖把表上的意向鎖變爲更強的鎖(如意向排他鎖轉爲排他鎖).獲得更強的鎖後，所有此事務持有的頁級和行級鎖被釋放，鎖開銷減少了。”(見http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_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本身)撤銷了。不只是在存儲過程和觸發器中，還原點在事務的任何時候都可用。
恢復速度
由於一次電源故障，你在達拉斯辦事處的數據庫服務器崩潰了。服務器重啓時數據庫必須自動迅速的恢復到一致狀態。
MSSQLServer重啓時恢復所需要的時間依靠檢查點(checkpoint)，因爲事務日誌必須回滾最後一個檢查點之後的所有活動的事務。檢查點由DBA週期性的創建。恢復一般需要幾分鐘，也許更長，這依賴於DBA在檢查點創建的頻率和隨之而來的性能降低之間所作的權衡 (見Microsoft SQL Server 2000, Microsoft Press,953頁)。
IB/FB在重啓時能立即恢復，因爲回滾活動的事務不需要特定的處理。IB/FB只需簡單的把每一標記爲“活動”的事務全部標記爲“回滾”即可。版本引擎會自動忽略這些記錄版本，通過垃圾收集，這些版本被移除——和數據庫正常運行時一樣。
事件
你的訂單錄入程序添加一條訂單時，相應的存貨必須減少。如果目前的存貨量降到了訂貨點，就需要通知存貨控制程序(運行在其他電腦上)。
使用MSSQLserver，必須寫一個COM對象操縱與存貨控制程序之間的通信，然後用存儲過程加載並調用COM對象的方法。
如果使用IB/FB，只需給觸發器添加一個POST_EVENT指令。在存貨控制程序中，添加一個事件操控組件，並通過設置其屬性註冊一下需要的事件。所有通信和回調機制在IB/FB中創建。你的團隊所要寫的代碼全都是業務邏輯。順便指出，如果某個用戶在添加了一些訂單後回滾事務，也不用擔心存貨系統收到錯誤的信息。直到事務提交，IB/FB纔會激活發出的事件。
培訓時間
培訓開發團隊所需要的時間是全部成本的一項重要組成，這個時間佔用的是交付你所開發項目的時間。這也是產品複雜度的一個很好的度量。Microsoft爲MSSQLServer2000的數據庫管理員提供了認證。“此認證適於那些來自物理數據庫設計的，開發邏輯數據模型，創建物理數據庫，使用Transact-SQL創建數據服務，管理和維護數據庫，配置和管理系統安全，監控和優化數據庫，以及安裝和配置SQLserver2000的個人。(見http://www.microsoft.com/traincert/mcp/mcdba/mcdba.asp)”“作爲SQLserver2000的MCDBA，至少應該有一年SQLserver的工作經驗。(http://www.microsoft.com/traincert/mcp/mcdba/mcdba.asp)”另外，認證需要22天的課堂指導和四門考試(見http://www.microsoft.com/traincert/mcp/mcdba/requirements.asp)。SQLserver是一個複雜的產品，所以它的DBA需要額外的培訓和經驗。
IB非常容易學習和管理，其最全面的培訓課程——旨在把一個完全的數據庫新手培訓成IB可信賴的管理者——僅需要5天。那些已經對數據庫管理熟悉的人們會發現，他們不需要專門的培訓，不時地參考一下IB的文檔就是所有要求了。
跨平臺支持
和桌面PC市場不同，應用服務器市場並不統一。除了Windows，Sun也處在重要的位置，特別在Web服務器方面，同時Linux正以驚人的速度增加它的佔有率。可能有時除了Windows，你還不得不支持各種服務器平臺。
當然，MSSQLserver只能在Windows下運行。另一方面，IB/FB在Sun Solaris, Linux和Windows下都可用,現在和將來你都擁有充分的靈活性。把IB/FB數據庫遷移到其他新的平臺，只需簡單的備份和恢復即可。
IB/FB也提供了各種連接數據庫的選擇——包括ODBC,JDBC,ADO.NET,DBExpress驅動和各種Delphi、C++Builder下的原生驅動，以確保開發人員能夠使用他們最喜歡的開發工具並部署他們特定的環境。。
成本
應用軟件也許分佈在許多地方或支持許多用戶，當使用到數據庫時，數據庫本身的許可費用會變爲項目開支的一個重要部分。下面的表格比較了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
|
結論
IB/FB使你擁有：
混合讀寫環境中卓越的併發性；
更靈活的觸發器支持；
更快的災難恢復；
更容易的事件管理；
更多的部署選擇；
跨平臺支持；
小巧；
系統要求更低；
更短的培訓時間；
更低的培訓費用；
更實惠的許可費用...
IB/FB以最低的成本和最短的時間，提供了創建強大應用所需要的特性。
作者簡介：Bill Todd是Database Group, Inc.(Phoenix旁邊的一個數據庫諮詢與開發公司)的總裁。合著過4本數據庫編程方面的書籍，發表超過100篇文章。在美國和歐洲的開發者大會上提交了超過20篇論文。