一、關係資料庫系統的優點
a．靈活性和建庫的簡單性：從軟體開發的前景來看，使用者與關係資料庫程式設計之間的介面是靈活與友好的。目前在多數RDDMS產品中使用標準查詢語言SQL，允許使用者幾乎毫無差別地從一個產品到另一個產品存取資訊。與關係資料庫介面的應用軟體具有相似的程式訪問機制，提供大量標準的資料存取方法。
b．結構簡單：從資料建模的前景看，關係資料庫具有相當簡單的結構（元組），可為使用者或程式提供多個複雜的檢視。資料庫設計和規範化過程也簡單易行和易於理解。由於關係資料庫的強有力的、多方面的功能，已經有效地支援許多資料庫納應用。
二、關係資料庫系統的缺點
a．資料型別表達能力差：從下一代應用軟體的發展角度來看，關係資料庫的根本缺陷在於缺乏直接構造與這些應用有關的資訊的型別表達能力，缺乏這種能力將產生以下有害的影響，例如：大多數RDBMS產品所採用的簡單型別在重構複雜資料的過程中將會出現效能問題；資料庫設計過程中的額外複雜性；RDBMS產品和程式語言在資料型別方面的不協調。
大多數現代的RDBMS產品已成熟地用於商務和財政方面，而這些領域不要求很高和很複雜的資料模型。雖然這些產品多多少少克服了一些以上所述的缺點，但從理論上看關係資料模型不直接支援複雜的資料型別，這是由於第一正規化的要求，所有的資料必須轉換為簡單的型別，如整數、實數、雙精度數和字串。
對於工程應用來說，這種不能支援複雜資料型別的典型結果就是需要額外地分解資料結構工作，這些被分解的結構不能直接表示應用資料，且從基本成分重構時也非常繁瑣和費時間。
b．複雜查詢功能差：關係資料庫系統的某些優點也同時是它的不足之處。雖然SQL語言為資料查詢提供了很好的定義方法，但當用於複雜資訊的查詢時可能是非常繁瑣的。此外，在工程應用時規範化的過程通常會產生大量的簡單表。在這種環境下由存取資訊產生的查詢必須處理大量的表和複雜的碼聯絡以及連線運算。
除非這些查詢以固定的例行程式方式提供，否則使用者就必須對SQL非常熟悉，以便適當地瀏覽資料庫，查出所需的資訊。然而，一旦查詢方式按固定例行程式方式進行，使用者最終就進行應用軟體的常規維護。但應用或人機介面軟體的變化又可能要求經常修改例行的查詢，資料庫結構的變化也可能導致例行查詢程式以及應用或人機介面軟體的失效。由於這些原因，關係資料庫系統的維護開銷可能是很大的。
由於關係資料庫不能提供足夠的構造能力及效能方面的原因，在進行較複雜的資料庫設計過程中，不可能將許多工程問題直接分解成一些簡單的部分。由於缺乏直接指標存取方法，所以查詢有關的資訊需要花費時間。
c．支援長事務能力差；由於RDBMS記錄鎖機制的顆粒度限制，對於支援多種記錄型別的大段資料的登記和檢查來說，簡單的記錄級的鎖機制是不夠的，但基於鍵值關係的較複雜的鎖機制來說卻很難推廣也難以實現。
d．環境應變能力差：在要求系統頻繁改變的環境下，關係系統的成本高且修改困難。在工程應用中支援"模式演變"（schema evolution）的功能是很重要的，而RDBMS不容易支援這種功能。另外，關係資料庫和程式語言所提供的資料型別的不一致，使得從一個環境轉換到另一個環境時需要多至30％的附加程式碼。
三、面向物件資料庫系統的優點
a．能有效地表達客觀世界和有效地查詢資訊：面向物件方法綜合了在關係資料庫中發展的全部工程原理、系統分析、軟體工程和專家系統領域的內容。面向物件的方法符合一般人的思維規律、即將現實世界分解成明確的物件，這些物件具有屬性和行為。系統設計人員用ODBMS建立的計算機模型能更直接反映客觀世界，終端使用者不管是否是計算機專業人員，都可以透過這些模型理解和評述資料庫系統。
工程中的一些問題對關係資料庫來說顯得太複雜，不採取面向物件的方法很難實現。從構造複雜資料的前景看，資訊不再需要手工地分解為細小的單元。ODBMS擴充套件了面向物件的程式設計環境，該環境可以支援高度複雜資料結構的直接建模。
b．可維護性好：在耦合性和內聚性方面，面向物件資料庫的效能尤為突出。這使得資料庫設計者可在儘可能少影響現存程式碼和資料的條件下修改資料庫結構，在發現有不能適合原始模型的特殊情況下，能增加一些特殊的類來處理這些情況而不影響現存的資料。如果資料庫的基本模式或設計發生變化，為與模式變化保持一致，資料庫可以建立原物件的修改版本。這種先進的耦合性和內聚性也簡化了在異種硬體平臺的網路上的分散式資料庫的執行。
c．能很好地解決"阻抗不匹配"（impedance mismatch）問題。面向物件資料庫還解決了一個關係資料庫執行中的典型問題：應用程式語言與資料庫管理系統對資料型別支援的不一致問題，這一問題通常稱之為阻抗不匹配問題。
四、面向物件資料庫系統的缺點
a．技術還不成熟。面向物件資料庫技術的根本缺點是這項技術還不成熟，還不廣為人知。與許多新技術一樣，風險就在於應用。從事面向物件資料庫產品和程式設計環境的銷售活動的公司還不令人信服，因為這些公司的歷史還相當短暫，就該十幾年前關係資料庫的情況一樣。ODBMS如今還存在著標準化問題，由於缺乏標準化，許多不同的ODBMS之間不能通用。此外，是否修改SQL以適應面向物件的程式，還是用新的物件查詢語言來代替它，目前還沒有解決，這些因素表明隨著標準化的出現，ODBMS還會變化。
b．面向物件技術需要一定的訓練時間：有面向物件系統開發經驗的公司的專業人員認為，要成功地開發這種系統的關鍵是正規的訓練，訓練之所以重要是由於面向物件資料庫的開發是從關係資料庫和功能分解方法轉化而來的，人們還需要學習一套新的開發方法使之與現有技術相結合。此外，面向物件系統開發的有關原理才剛開始具有雛形，還需一段時間在可靠性、成本等方面令人可接受。
c．理論還需完善：從正規的計算機科學方面看，還需要設計出堅實的演算或理論方法來支援ODBMS的產品。此外，既不存在一套資料庫設計方法學，也沒有關於面向物件分析的一套清晰的概念模型，怎樣設計獨立於物理儲存的資訊還不明確。
面向物件資料庫和關係資料庫系統之間的爭論不同於70年代關係資料庫和網狀資料庫的爭論，那時的爭論是在同一主要領域（即商業事務應用）中究竟是誰代替誰的問題。現在是肯定關係資料庫系統基本適合商業事務處理的前提下，對非傳統的應用，特別是工程中的應用用面向物件資料庫來補充不足的問題。面向物件資料庫系統將成為下一代資料庫的典型代表，並和關係資料庫系統並存（而不是替代）。它將在不同的應用領域支援不同的應用需求。
一、關係資料庫系統的優點
a．靈活性和建庫的簡單性：從軟體開發的前景來看，使用者與關係資料庫程式設計之間的介面是靈活與友好的。目前在多數RDDMS產品中使用標準查詢語言SQL，允許使用者幾乎毫無差別地從一個產品到另一個產品存取資訊。與關係資料庫介面的應用軟體具有相似的程式訪問機制，提供大量標準的資料存取方法。
b．結構簡單：從資料建模的前景看，關係資料庫具有相當簡單的結構（元組），可為使用者或程式提供多個複雜的檢視。資料庫設計和規範化過程也簡單易行和易於理解。由於關係資料庫的強有力的、多方面的功能，已經有效地支援許多資料庫納應用。
二、關係資料庫系統的缺點
a．資料型別表達能力差：從下一代應用軟體的發展角度來看，關係資料庫的根本缺陷在於缺乏直接構造與這些應用有關的資訊的型別表達能力，缺乏這種能力將產生以下有害的影響，例如：大多數RDBMS產品所採用的簡單型別在重構複雜資料的過程中將會出現效能問題；資料庫設計過程中的額外複雜性；RDBMS產品和程式語言在資料型別方面的不協調。
大多數現代的RDBMS產品已成熟地用於商務和財政方面，而這些領域不要求很高和很複雜的資料模型。雖然這些產品多多少少克服了一些以上所述的缺點，但從理論上看關係資料模型不直接支援複雜的資料型別，這是由於第一正規化的要求，所有的資料必須轉換為簡單的型別，如整數、實數、雙精度數和字串。
對於工程應用來說，這種不能支援複雜資料型別的典型結果就是需要額外地分解資料結構工作，這些被分解的結構不能直接表示應用資料，且從基本成分重構時也非常繁瑣和費時間。
b．複雜查詢功能差：關係資料庫系統的某些優點也同時是它的不足之處。雖然SQL語言為資料查詢提供了很好的定義方法，但當用於複雜資訊的查詢時可能是非常繁瑣的。此外，在工程應用時規範化的過程通常會產生大量的簡單表。在這種環境下由存取資訊產生的查詢必須處理大量的表和複雜的碼聯絡以及連線運算。
除非這些查詢以固定的例行程式方式提供，否則使用者就必須對SQL非常熟悉，以便適當地瀏覽資料庫，查出所需的資訊。然而，一旦查詢方式按固定例行程式方式進行，使用者最終就進行應用軟體的常規維護。但應用或人機介面軟體的變化又可能要求經常修改例行的查詢，資料庫結構的變化也可能導致例行查詢程式以及應用或人機介面軟體的失效。由於這些原因，關係資料庫系統的維護開銷可能是很大的。
由於關係資料庫不能提供足夠的構造能力及效能方面的原因，在進行較複雜的資料庫設計過程中，不可能將許多工程問題直接分解成一些簡單的部分。由於缺乏直接指標存取方法，所以查詢有關的資訊需要花費時間。
c．支援長事務能力差；由於RDBMS記錄鎖機制的顆粒度限制，對於支援多種記錄型別的大段資料的登記和檢查來說，簡單的記錄級的鎖機制是不夠的，但基於鍵值關係的較複雜的鎖機制來說卻很難推廣也難以實現。
d．環境應變能力差：在要求系統頻繁改變的環境下，關係系統的成本高且修改困難。在工程應用中支援"模式演變"（schema evolution）的功能是很重要的，而RDBMS不容易支援這種功能。另外，關係資料庫和程式語言所提供的資料型別的不一致，使得從一個環境轉換到另一個環境時需要多至30％的附加程式碼。
三、面向物件資料庫系統的優點
a．能有效地表達客觀世界和有效地查詢資訊：面向物件方法綜合了在關係資料庫中發展的全部工程原理、系統分析、軟體工程和專家系統領域的內容。面向物件的方法符合一般人的思維規律、即將現實世界分解成明確的物件，這些物件具有屬性和行為。系統設計人員用ODBMS建立的計算機模型能更直接反映客觀世界，終端使用者不管是否是計算機專業人員，都可以透過這些模型理解和評述資料庫系統。
工程中的一些問題對關係資料庫來說顯得太複雜，不採取面向物件的方法很難實現。從構造複雜資料的前景看，資訊不再需要手工地分解為細小的單元。ODBMS擴充套件了面向物件的程式設計環境，該環境可以支援高度複雜資料結構的直接建模。
b．可維護性好：在耦合性和內聚性方面，面向物件資料庫的效能尤為突出。這使得資料庫設計者可在儘可能少影響現存程式碼和資料的條件下修改資料庫結構，在發現有不能適合原始模型的特殊情況下，能增加一些特殊的類來處理這些情況而不影響現存的資料。如果資料庫的基本模式或設計發生變化，為與模式變化保持一致，資料庫可以建立原物件的修改版本。這種先進的耦合性和內聚性也簡化了在異種硬體平臺的網路上的分散式資料庫的執行。
c．能很好地解決"阻抗不匹配"（impedance mismatch）問題。面向物件資料庫還解決了一個關係資料庫執行中的典型問題：應用程式語言與資料庫管理系統對資料型別支援的不一致問題，這一問題通常稱之為阻抗不匹配問題。
四、面向物件資料庫系統的缺點
a．技術還不成熟。面向物件資料庫技術的根本缺點是這項技術還不成熟，還不廣為人知。與許多新技術一樣，風險就在於應用。從事面向物件資料庫產品和程式設計環境的銷售活動的公司還不令人信服，因為這些公司的歷史還相當短暫，就該十幾年前關係資料庫的情況一樣。ODBMS如今還存在著標準化問題，由於缺乏標準化，許多不同的ODBMS之間不能通用。此外，是否修改SQL以適應面向物件的程式，還是用新的物件查詢語言來代替它，目前還沒有解決，這些因素表明隨著標準化的出現，ODBMS還會變化。
b．面向物件技術需要一定的訓練時間：有面向物件系統開發經驗的公司的專業人員認為，要成功地開發這種系統的關鍵是正規的訓練，訓練之所以重要是由於面向物件資料庫的開發是從關係資料庫和功能分解方法轉化而來的，人們還需要學習一套新的開發方法使之與現有技術相結合。此外，面向物件系統開發的有關原理才剛開始具有雛形，還需一段時間在可靠性、成本等方面令人可接受。
c．理論還需完善：從正規的計算機科學方面看，還需要設計出堅實的演算或理論方法來支援ODBMS的產品。此外，既不存在一套資料庫設計方法學，也沒有關於面向物件分析的一套清晰的概念模型，怎樣設計獨立於物理儲存的資訊還不明確。
面向物件資料庫和關係資料庫系統之間的爭論不同於70年代關係資料庫和網狀資料庫的爭論，那時的爭論是在同一主要領域（即商業事務應用）中究竟是誰代替誰的問題。現在是肯定關係資料庫系統基本適合商業事務處理的前提下，對非傳統的應用，特別是工程中的應用用面向物件資料庫來補充不足的問題。面向物件資料庫系統將成為下一代資料庫的典型代表，並和關係資料庫系統並存（而不是替代）。它將在不同的應用領域支援不同的應用需求。