如何設計ADO代碼操作解決方案
有許多種辦法可以連上一個數據庫. 你可以用System DSN, DSN-less連接或是本地的OLEDB providerADO代碼? 這是什么什么玩藝兒? 也許你們中的許多人以前沒有聽說過. 要回答這個問題,我們先得回顧一下數據庫連接的歷史。
期的數據庫連接是非常困難的. 每個數據庫的格式都不一樣,開發者得對他們所開發的每種數據庫的底層API有深刻的了解. 因此,能處理各種各樣數據庫的通用的API就應運而生了. 也就是現在的ODBC(Open Database Connectivity), ODBC是人們在創建通用API的早期產物. 有許多種數據庫遵從了這種標準,被稱為ODBC兼容的數據庫. ODBC兼容的數據庫包括Access, MS-SQL Server, ADO代碼等.。#t#
ADO代碼并不是完美無缺的,它仍然含有大量的低級的調用,開發ODBC應用程序仍較困難. 開發者不得不將大量的精力花在底層的數據庫通信中,而不能專注于他們所要處理的數據. 后來微軟提出了一個解決方案: DAO(Data Access Objects). DAO的代碼看起來象這樣:
- objItem.AddNew
- objItem.Name = "Chair"
- objItem.Price = 10
- objItem.Update
你也許看過DAO的代碼. 后來DAO演變為RDO(Remote Data Objects, 為分布式數據庫體系設計), 再后來是ADO. 盡管它們都有各自的不足之處. 根據微軟的說法,"ODBC提供了本地SQL數據的存取,DAO提供了高級的數據對象". ADO代碼都需要數據以SQL(Structured Query Language)的格式存儲. 針對這些缺陷,微軟提出了OLEDB,一個基于COM的數據存儲對象,能提供對所有類型的數據的操作,甚至能在離線的情況下存取數據(比方說,你使用的是你的便攜機,你可以毫不費力地看到最后一次數據同步時的數據映像).
OLEDB位于ADO代碼層與應用程序之間. 在你的ASP頁面里,ADO是位于OLEDB之上的"應用程序". 你的ADO調用先被送到OLEDB,然后再交由ODBC處理. 你可以直接連接到OLEDB層,如果你這么做了,你將看到服務器端游標(recordset的缺省的游標,也是最常用的游標)性能的提升. 那我們該如何直接連接到OLEDB呢?
