關系數據庫模型支持了SQL語言的發展並且擁有強大的理論基礎為後盾(基於一階的謂詞邏輯)目前SQL已經成為定義和操縱關系數據庫的標准語言
關系數據模型的另一個好處在於它的簡單性適合聯機事務處理(OLTP)支持數據獨立性但是關系數據模型特別是RDBMS同樣存在許多的不足之處詳細內容請參考下文
一對現實世界實體的表達能力比較弱
規范化通常導致表與現實世界中的實體不對應它將現實世界中的實體分割成幾張表來顯示以物理表示法來反映實體結構這樣效率會比較差常常要在查詢處理中進行很多連接操作
二語義過載
關系模型表達數據和數據間關系的構造只有一種——表例如為了表達實體A和實體B之間的多對多(*:*)關系我們需要創建三張表兩個分別用於表達實體A和B第三張表用於表達實體間的關系它沒有一種機制來區分實體和關系也無法區分在實體間存在的不同種類的關系例如一個:*關系可能是HasSupervisesManages等等如果可以進行區分也許我們就可以將語義構建到操作中所以我們說關系模型語義過載了
三不能很好的支持業務規則
很多商業化系統不能完全支持實體和參照完整性域等業務規則所以需要將它們內置到應用程序中這樣當然是危險的而且容易導致做重復的工作更糟糕的是可能還會引起不一致現象而且在關系模型中不支持其他類型的業務規則這又意味著它們需要被構建到DBMS或應用程序中
四有限的操作
關系模型只有一些固定的操作集例如面向集合和記錄的操作操作是在SQL規格說明中提供的但是SQL目前不允許指定新的操作因此在給許多現實世界對象的行為建模就有了太多的限制例如一個GIS應用程序典型的使用點線線組多邊形和一些處理距離交叉點和包含關系的操作
五處理遞歸查詢困難
數據的原子性意味著在關系模型中不允許出現重復的數據組這樣就導致了處理遞歸查詢極為困難遞歸查詢就是那些有關表和自身直接或間接的關系的查詢為了解決這個問題SQL可以嵌入在一個高級程序設計語言中由高級程序設計語言來提供支持反復操作的功能而且很多RDBMS提供了具有類似結構的報表書寫程序不管是哪種情況都是應用程序而不是系統的內在功能提供了所需的功能
六阻抗失配
直到最新版本的SQL標准都缺少完全的計算功能為了解決這個問題並且提供更多的靈活性SQL標准提供嵌入式SQL來幫助開發更加復雜的數據庫應用程序但是這引起了阻抗不匹配(impedance mismatch)的問題因為我們將兩種不同的程序設計模式混合在了一起
SQL是一種處理行數據的聲明性語言而諸如C語言這樣的高級語言則是過程化的語言一次只能處理一行數據
SQL和GL使用不同的模型來表達數據比如SQL提供內置的數據類型Date(日期型)和Interval(時間間隔型)而在傳統的編程語言中卻沒有這樣的類型因此就需要應用程序在兩種表示法之間進行轉換而這樣做無論從程序設計的工作量還是運行時資源的使用來看都是低效的而且由於我們使用兩種不同的系統因此不可能將類型檢測作為一個整體自動進行
注SQL標准(SQL)通過引入許多新的特征已經彌補了上文中講述的一些不足之處
From:http://tw.wingwit.com/Article/program/SQL/201311/16241.html
