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