每個數據的訪問都用自己的通信協議，包括還有不同的接口調用，參數傳遞。在同一個程序裡要使用不同數據庫裡的信息，按照正常的情況來說，那就要寫不同的數據庫連接的方法，就像在程序裡寫了多個精簡版的 數據庫 客戶端。這樣的編程方式肯定會讓人不好難受，所以就期望能夠有一種統一的訪問數據庫的方式，大家都用這一種方式去連接數據庫，那麼將減少很多痛苦。
話說微軟是第一個給大家帶來曙光的人，推出了ODBC的概念，從此所有的程序都不用自己寫數據庫連接程序了，從此跨入了解放時代。ODBC是一組基於C語言的API，它能兼容不同的數據庫，然後提供統一的訪問接口，這樣就為大家節省出了YY的時間。
在ODBC推出後多年，有出了一個新概念OLE DB。這個是ODBC的升級版，因為一切都開始面向對象了，所以這個自然就是以對象方式來實現的。而且在性能方面也有了一些提高，自此OLE DB成為微軟的新寵。
ODBC、OLE DB都是底層的數據庫訪問接口，使用起來不是很方便、容易，大家YY的時間又被占用的，為此微軟決定再次解放大家、所以就出來了ADO的概念。很顯然這是一個對象，就是對OLE DB、ODBC的高層封裝，把大家經常要做的數據庫操作都給直接提供出來，大家的YY時間再次被解救回來了。
不過在這期間Sun公司也沒閒著，為了更大層次的解救JAVA程序猿們的YY時間，就單獨寫了一套專門用於JAVA的數據庫訪問接口JDBC，聽名字就知道是山寨創意了。換湯不換藥，唯一的好處就是java代碼裡調用會更舒服，自己家養的東西肯定用起來更順手。
當然sun除了山寨創意外，還保留了對ODBC的調用接口【JDBC-ODBC橋】，以防不時之需；這樣萬一有一天除了一個新的東西只有ODBC支持，JDBC不支持。這時還不至於太有壓力。當然ODBC的支持也是目前最廣的，某些非主流的數據庫文件的訪問接口也都支持，所以還是留一手的好。
這樣的話，數據庫訪問方式就開始明朗了。見下：
這樣看來，用途最廣、最底層的就是ODBC了。基本所有其它的都會可能調用它，JDBC、OLE DB是一個等級的；一個是sun的，一個是微軟的；ADO不是直接訪問的程序，只是一個訪問快速通道而已。
注：所有的鏈接方式都需要本機有相應的驅動，而驅動是和具體的數據庫是對應的。這樣就會有3類驅動類型，每類訪問N種數據庫都要N個驅動。
