M i c r o s o f t在Wi n d o w s平台中提供了数种不同的数据存取技术。这些不同的数据存取技术各有它们的特性和出现的原因。M i c r o s o f t也从实现这些不同的数据存取技术中学习到了许多经验，并且根据这些经验开发出新一代技术， A D O便是一个非常好的范例。现在就让我们从各种不同的数据存取技术角度来看看每一种技术出现时，它是为了存取什么样的数据源。 1. ODBC 1 9 9 2年M i c r o s o f t和S y b a s e、D i g i t a l共同制定了O D B C标准接口，以单一的ODBC API来存取各种不同的数据库。随后O D B C便获得了许多数据库厂商和T h i r d - P a r t y的支持而逐渐成为标准的数据存取技术。 O D B C以当时的业界标准规范X/Open Call-Level Interface(CLI)和I S O / I E C9075-3 Call-LevelInterface(SQL/CLI)为涵盖的范围，因而支持了广阔的数据库。虽然O D B C在初期的版本中执行效率不佳，而且功能有限，因此也为人们所贬低。 但是，随着M i c r o s o f t不断地改善O D B C，使O D B C的执行效率不断增加， O D B C驱动程序的功能也日渐齐全。到目前， O D B C已经是一个稳定并且执行效率良好的数据存取引擎。不过O D B C仅支持关系数据库，以及传统的数据库数据类型，并且只以C / C + +语言A P I形式提供服务，因而无法符合日渐复杂的数据存取应用，也无法让脚本语言使用。因此M i c r o s o f t除了O D B C之外，也推出了其他的数据存取技术以满足程序员不同的需要。 2. DAO 1 9 9 3年M i c r o s o f t为了让程序员能够存取A c c e s s数据库，使用OLE Automation技术封装了Jet Engine。这些使用Jet Engine存取A c c e s s数据库的OLE AutomationO b j e c t便称为Data Access Object(DAO)。D A O能够存取x B a s e的数据库以及E x c e l文件，并且能够结合O D B C存取关系 数据库。但是D A O毕竟主要的设计目的是存取A c c e s s数据库，因此D A O在存取A c c e s s数据库时非常有效率，但是在存取其他的数据源时却表现得不怎么好。目前D A O已经慢慢接近维护的状态，因此建议各位尽量不要在新的项目中使用D A O。 3. RDO 由于D A O在结合O D B C存取关系数据库时表现得并不好，因此在1 9 9 5年M i c r o s o f t同样以OLE Automation技术直接封装ODBC API，让程序员能够存取关系数据库。这种数据存取技术便称为Remote Data Object(RDO)。M i c r o s o f t之所以推出R D O，是因为ODBC API是非常复杂的A P I，许多程序员 无法直接使用ODBC API来开发应用程序，因此M i c r o s o f t以简化的R D O对象让程序员能够较为简单存取数据。此外，通过R D O，V B和脚本语言也能够存取各种关系数据库。不过目前R D O也已经逐渐地被放弃了，因此建议各位也不要在新的项目中使用R D O，毕竟R D O只能算是一个过渡性质的数据存取解决方案。 4. OLE-DB 随着数据源日益复杂化，现今的应用程序很可能需要从不同的数据源取得数据，加以处理，再把处理过的数据输出到另外一个数据源中。更麻烦的是这些数 据源可能不是传统的关系数据库，而可能是E x c e l文件，E m a i l或I n t e r n e t / I n t r a n e t上的电子签名信息。M i c r o s o f t为了让应用程序能够以统一的方式存取各种不同的数据源，在1 9 9 7年提出了Universal Data Access(UDA)架构。U D A以C O M技术为核心，协助程序员存取企业中各类不同的数据源。U D A以O L E - D B (属于操作系统层次的软件)做为技术的骨架。O L E - D B定义了统一的C O M接口做为存取各类异质数据源的标准，并且封装在一组C O M对象之中。藉由O L E - D B，程序员就可以使用一致的方式来存取各种数据。 5. ADO 虽然O L E - D B允许程序员存取各类数据，是一个非常良好的架构，但是由于O L E - D B太底层化，而且在使用上非常复杂，需要程序员拥有高超的技巧，因此只有少数的程序员才有办法使用O L E - D B。这让O L E - D B无法广为流行。为了解决这个问题，并且让V B和脚本语言也能够藉由O L E - D B存取各种数据源， M i c r o s o f t同样以C O M技术封装O L E - D B为A D O对象，简化了程序员数据存取的工作。由于A D O成功地封装了O L E - D B大部分的功能，并且大量简化了数据存取工作，因此A D O也逐渐被愈来愈多的程序员所接受。 6. ADO的架构 A D O主要是让应用程序或We b应用程序存取各种不同的数据源。A D O封装了O L E - D B复杂的接口，以极为简单的C O M接口存取数据。图1 - 1是A D O的架构图。从图1 - 1我们可以看到，A D O能够藉由O L E - D B存取传统的关系数据库，或F l a t - F i l e类型的数据库；也可以存取非传统的数据，例如文字、E m a i l、声音、图形、影像等。更可以通过O L E - D B，藉由C o n n e c t o r来存取大型的数据源，例如C I C S等。但是不管应用程序要存取哪一种数据源，应用程序都只需要使用A D O，而不需要使用各种不同的复杂A P I来存取不同的数据，这样就可以大大简化应用程序员的工作。图1 - 2则是加入D A O和R D O存取技术的架构。从图1 - 2中可以看到， D A O和R D O只是封装了O D B C，因此只能存取关系数据库、F l a t - F i l e数据或特殊O D B C驱动程序能够存取的数据；对于非传统的数据源则无能为力。 图1-1 ADO数据存取架构 图1-2 ADO/DAO/RDO数据存取架构A D O藉由O L E - D B来存取不同数据源的数据，因此程序员要使用A D O技术存取数据，就必须搭配使用O L E - D B驱动程序，而且最好是原生的O L E - D B驱动程序，而避免使用O L E - D B再加上O D B C驱动程序的架构。O L E - D B使用了C o n s u m e r- P r o v i d e r架构来提供数据存取的服务，它使用了三个不同的元素来提供数据存取的服务。下面分别讲述这些元素。
1. ODBC
1 9 9 2年M i c r o s o f t和S y b a s e、D i g i t a l共同制定了O D B C标准接口，以单一的ODBC API来存取各种不同的数据库。随后O D B C便获得了许多数据库厂商和T h i r d - P a r t y的支持而逐渐成为标准的数据存取技术。
O D B C以当时的业界标准规范X/Open Call-Level Interface(CLI)和I S O / I E C9075-3 Call-LevelInterface(SQL/CLI)为涵盖的范围，因而支持了广阔的数据库。虽然O D B C在初期的版本中执行效率不佳，而且功能有限，因此也为人们所贬低。
但是，随着M i c r o s o f t不断地改善O D B C，使O D B C的执行效率不断增加， O D B C驱动程序的功能也日渐齐全。到目前， O D B C已经是一个稳定并且执行效率良好的数据存取引擎。不过O D B C仅支持关系数据库，以及传统的数据库数据类型，并且只以C / C + +语言A P I形式提供服务，因而无法符合日渐复杂的数据存取应用，也无法让脚本语言使用。因此M i c r o s o f t除了O D B C之外，也推出了其他的数据存取技术以满足程序员不同的需要。
2. DAO
1 9 9 3年M i c r o s o f t为了让程序员能够存取A c c e s s数据库，使用OLE Automation技术封装了Jet Engine。这些使用Jet Engine存取A c c e s s数据库的OLE AutomationO b j e c t便称为Data Access Object(DAO)。D A O能够存取x B a s e的数据库以及E x c e l文件，并且能够结合O D B C存取关系
数据库。但是D A O毕竟主要的设计目的是存取A c c e s s数据库，因此D A O在存取A c c e s s数据库时非常有效率，但是在存取其他的数据源时却表现得不怎么好。目前D A O已经慢慢接近维护的状态，因此建议各位尽量不要在新的项目中使用D A O。
3. RDO
由于D A O在结合O D B C存取关系数据库时表现得并不好，因此在1 9 9 5年M i c r o s o f t同样以OLE Automation技术直接封装ODBC API，让程序员能够存取关系数据库。这种数据存取技术便称为Remote Data Object(RDO)。M i c r o s o f t之所以推出R D O，是因为ODBC API是非常复杂的A P I，许多程序员
无法直接使用ODBC API来开发应用程序，因此M i c r o s o f t以简化的R D O对象让程序员能够较为简单存取数据。此外，通过R D O，V B和脚本语言也能够存取各种关系数据库。不过目前R D O也已经逐渐地被放弃了，因此建议各位也不要在新的项目中使用R D O，毕竟R D O只能算是一个过渡性质的数据存取解决方案。
4. OLE-DB
随着数据源日益复杂化，现今的应用程序很可能需要从不同的数据源取得数据，加以处理，再把处理过的数据输出到另外一个数据源中。更麻烦的是这些数
据源可能不是传统的关系数据库，而可能是E x c e l文件，E m a i l或I n t e r n e t / I n t r a n e t上的电子签名信息。M i c r o s o f t为了让应用程序能够以统一的方式存取各种不同的数据源，在1 9 9 7年提出了Universal Data Access(UDA)架构。U D A以C O M技术为核心，协助程序员存取企业中各类不同的数据源。U D A以O L E - D B (属于操作系统层次的软件)做为技术的骨架。O L E - D B定义了统一的C O M接口做为存取各类异质数据源的标准，并且封装在一组C O M对象之中。藉由O L E - D B，程序员就可以使用一致的方式来存取各种数据。
5. ADO
虽然O L E - D B允许程序员存取各类数据，是一个非常良好的架构，但是由于O L E - D B太底层化，而且在使用上非常复杂，需要程序员拥有高超的技巧，因此只有少数的程序员才有办法使用O L E - D B。这让O L E - D B无法广为流行。为了解决这个问题，并且让V B和脚本语言也能够藉由O L E - D B存取各种数据源， M i c r o s o f t同样以C O M技术封装O L E - D B为A D O对象，简化了程序员数据存取的工作。由于A D O成功地封装了O L E - D B大部分的功能，并且大量简化了数据存取工作，因此A D O也逐渐被愈来愈多的程序员所接受。
6. ADO的架构
A D O主要是让应用程序或We b应用程序存取各种不同的数据源。A D O封装了O L E - D B复杂的接口，以极为简单的C O M接口存取数据。图1 - 1是A D O的架构图。从图1 - 1我们可以看到，A D O能够藉由O L E - D B存取传统的关系数据库，或F l a t - F i l e类型的数据库；也可以存取非传统的数据，例如文字、E m a i l、声音、图形、影像等。更可以通过O L E - D B，藉由C o n n e c t o r来存取大型的数据源，例如C I C S等。但是不管应用程序要存取哪一种数据源，应用程序都只需要使用A D O，而不需要使用各种不同的复杂A P I来存取不同的数据，这样就可以大大简化应用程序员的工作。图1 - 2则是加入D A O和R D O存取技术的架构。从图1 - 2中可以看到， D A O和R D O只是封装了O D B C，因此只能存取关系数据库、F l a t - F i l e数据或特殊O D B C驱动程序能够存取的数据；对于非传统的数据源则无能为力。
图1-1 ADO数据存取架构
图1-2 ADO/DAO/RDO数据存取架构A D O藉由O L E - D B来存取不同数据源的数据，因此程序员要使用A D O技术存取数据，就必须搭配使用O L E - D B驱动程序，而且最好是原生的O L E - D B驱动程序，而避免使用O L E - D B再加上O D B C驱动程序的架构。O L E - D B使用了C o n s u m e r- P r o v i d e r架构来提供数据存取的服务，它使用了三个不同的元素来提供数据存取的服务。下面分别讲述这些元素。