對象型是6種VB型中的類型之一
按理說，“對象型關係資料庫”是不可能的，關係資料庫與對象資料庫保存信息的基本結構就不可能相同。
在關係資料庫中，你需要定義各個表的欄位結構，資料庫系統於是可以知道每個記錄的確定的位元組數，並且把記錄當作二進制數據塊處理，因而速度非常快。
按理說，“對象型關係資料庫”是不可能的，關係資料庫與對象資料庫保存信息的基本結構就不可能相同。
在關係資料庫中，你需要定義各個表的欄位結構，資料庫系統於是可以知道每個記錄的確定的位元組數，並且把記錄當作二進制數據塊處理，因而速度非常快。
對象資料庫是以“元數據”為基礎的。元數據不需要預先定義結構，因此也不能直接用很“底層”的計算機檔案處理技術來管理。例如，定義一個“員工”資料表，但是其中到底應該有多少個欄位、每個欄位都是什麼含義、以及採用什麼數據格式都允許不確定甚至隨時改變，而且每個欄位內部不但可以是基本的數據類型，還可以是用戶定義類型（例如其它多個數據或者記錄的集合），甚至是另一個表。
可能聽起來比較糊塗。可以用一個最接近、最易懂的東西作說明,那就是XML。傳統的計算機遠程組件之間的通訊協定往往都是定長的，格式非常死板的，二進制的。協定的一個版本與另一個版本之間、或者一種實現方言與其它方言之間經常造成通訊的不暢甚至導致應用程式崩潰。而XML能夠表達“自定義”的數據，對信息的排列次序、內容多少沒有要求，因此可以表達對同一對象的各種需求。
對象資料庫負責(以離散的方式)保存數據、提供查詢工具、套用系統等等。
理論上，對象資料庫和關係資料庫相比，其查詢速度就像龜兔賽跑一樣。但是，對象資料庫可以使數據分析程式非常容易開發（因為不需要定義數據結構，一切都是針對對象的單個屬性在運行時才去判斷其是否存在的，比windows註冊表的結構還要具有“伸縮性”）。
現在，Word、Excel甚至應用程式都在向XML形式發展。也可以把對象資料庫看作它們在伺服器端的統一的管理系統。主要的問題就是,這么低的查詢效率，使用它是否值得？
