ADO DataSet的结构允许基于查询返回的结果创建Recordset。数据访问引擎会检查结果集中的数据列，并根据该信息填充Recordset对象的Fields集合，设置名称、数据类型等。下面进行相关说明。
可以使用少数代码行，让ADO.NET自动检查结果的结构；也可以使用较多代码，其中包含了有关查询结果结构的元数据。
那么为什么要选择需要编写较多代码的选项呢？最主要的优点就在于其功能性更强、性能更佳。但是代码较多时又怎么会使应用程序的运行速度更快呢？这似乎有悖于人们的直觉感受，不是吗？
除非您正编写一个专用查询工具，否则您通常事先就知道查询结果的结构形式。例如，大多数ADO DataSet的结构形式都与下例相似。Dim rs as Recordset'在此处声明其他变量…初始化变量并与数据库建立连接：
- rs.Open strSQL, cnDatabase, adOpenStatic, adLockOptimistic, adCmdText
- Do While Not rs.EOF
- List1.AddItem rs.Fields("UserName").Value
- rs.MoveNext
- Loop
在此代码段中，编程人员知道该查询包含一个名为UserName的列。关键就在于一个开发人员通常都知道查询会返回哪些列，以及这些列使用何种数据类型。但是ADO并不能事先了解查询结果的形式。结果，ADO必须对OLE DB提供程序进行查询，提出诸如“查询的结果中有多少列？
”，“这些列中每一列的数据类型是什么？”，“这些数据来自何方？”和“该查询中所引用的每个表的主键字段是什么？”等问题。OLE DB提供程序可以回答这些问题中的一部分，但是很多时候它都必须回调数据库。#t#
为获取查询结果，并且将该数据存储在DataSet对象中，ADO DataSet的结构需要知道此类问题的答案。您可以自己提供这些信息，也可以强制ADO.NET从提供程序获取信息。当选择自己提供信息时，代码的运行速度就能加快，这是因为：与通过代码提供元数据相比，在运行时向提供程序询问此信息会使性能大幅降低。
尽管通过编写代码来准备ADO DataSet的结构可以提高应用程序的性能，但编写代码可能非常沉闷乏味。幸运的是，Visual Studio包含了设计时数据访问特性，这些特性为我们综合了两者***秀的性能。
例如，您可以创建一个基于查询、表名称或存储过程的DataSet对象，然后配置向导就会生成ADO.NET代码，来运行此查询，并支持将更新提交给数据库。在下面的章节中将会详细讨论许多此类Visual Studio特性。
