據(jù)庫banner通用.jpg)
關系數(shù)據(jù)庫系統(tǒng)的優(yōu)點：
1.靈活性和建庫的簡單性
從軟件開發(fā)的角度來看，用戶與關系數(shù)據(jù)庫編程之間的接口是靈活而友好的。當前，大多數(shù)RDDMS產品中都使用標準查詢語言SQL，這使用戶幾乎可以毫無區(qū)別地從一種產品訪問另一種產品的信息。與關系數(shù)據(jù)庫接口的應用程序軟件具有類似的程序訪問機制，并提供了大量的標準數(shù)據(jù)訪問方法。
2.結構簡單
從數(shù)據(jù)建模的角度來看，關系數(shù)據(jù)庫具有相當簡單的結構（元組），可以為用戶或程序提供多個復雜的視圖。數(shù)據(jù)庫設計和標準化過程也非常簡單，易于實現(xiàn)和易于理解。由于關系數(shù)據(jù)庫的強大功能和多方面的功能，它有效地支持了許多數(shù)據(jù)庫應用程序。
關系數(shù)據(jù)庫系統(tǒng)的缺點：
1.數(shù)據(jù)類型表達能力差
從下一代應用程序軟件的開發(fā)角度來看，關系數(shù)據(jù)庫的根本缺陷在于缺乏直接構造與這些應用程序相關的信息類型的能力。缺少此功能將產生以下有害影響，例如：大多數(shù)RDBMS產品使用在為簡單類型的復雜數(shù)據(jù)重建過程中會出現(xiàn)性能問題。數(shù)據(jù)庫設計過程中的額外復雜性；RDBMS產品和編程語言之間數(shù)據(jù)類型的不協(xié)調。
大多數(shù)現(xiàn)代RDBMS產品已經在商業(yè)和金融領域成熟使用，并且這些領域不需要非常高和復雜的數(shù)據(jù)模型。盡管這些產品或多或少地克服了上述一些缺點，但是從理論上講，關系數(shù)據(jù)模型并不直接支持復雜的數(shù)據(jù)類型。這是由于第一個范式的要求，所有數(shù)據(jù)都必須轉換為簡單類型。例如整數(shù)，實數(shù)，雙精度數(shù)和字符串。
對于工程應用，這種無法支持復雜數(shù)據(jù)類型的典型結果是需要分解數(shù)據(jù)結構。這些分解的結構不能直接表示應用程序數(shù)據(jù)，并且從基本組件進行重建也非常繁瑣且耗時。
2.復雜的查詢功能差
關系數(shù)據(jù)庫系統(tǒng)的一些優(yōu)點也是它的缺點。盡管SQL語言為數(shù)據(jù)查詢提供了一種很好的定義方法，但是當用于查詢復雜信息時，它可能會非常麻煩。另外，工程應用中的標準化過程通常會產生大量簡單表。在這種環(huán)境中，通過訪問信息生成的查詢必須處理大量的表以及復雜的代碼連接和聯(lián)接操作。
除非在固定的例程中提供這些查詢，否則用戶必須非常熟悉SQL，才能正確瀏覽數(shù)據(jù)庫以查找所需的信息。但是，一旦以固定的常規(guī)模式執(zhí)行查詢模式，用戶最終將對應用程序軟件進行常規(guī)維護。但是，應用程序或人機界面軟件的更改可能需要經常修改例行查詢，并且數(shù)據(jù)庫結構的更改也可能導致例行查詢程序和應用程序或人機界面軟件失敗。由于這些原因，關系數(shù)據(jù)庫系統(tǒng)的維護開銷可能非常大。
由于關系數(shù)據(jù)庫無法提供足夠的構造功能和性能，因此在更復雜的數(shù)據(jù)庫設計過程中無法將許多工程問題直接分解為簡單的部分。由于缺少直接的指針訪問方法，因此需要花費一些時間來查詢相關信息。
3.長期支持能力差
由于RDBMS記錄鎖定機制的粒度限制，簡單的記錄級鎖定機制不足以注冊和檢查支持多種記錄類型的大型數(shù)據(jù)，但基于鍵-值關系的更復雜的鎖定機制這是很難促進和實現(xiàn)的。
4.環(huán)境彈性差
在需要頻繁更改系統(tǒng)的環(huán)境中，關系系統(tǒng)的成本很高，并且很難進行修改。在工程應用中支持“模式演變”功能非常重要，RDBMS無法輕松支持此功能。另外，關系數(shù)據(jù)庫和編程語言提供的數(shù)據(jù)類型不一致，使得從一種環(huán)境到另一種環(huán)境的轉換最多需要30％的附加代碼。
