在我们创建应用程序来访问数据存储时，我们的确考虑一下要采取何种类型的数据访问，以及如何使用这些数据。在使用过后我们可以发现，相对于DataReader来说，DataSet过于复杂，相应的，也就丢失了一些操作性能并会占用一些内存。因此，无论何时我们都应该优先考虑使用DataReader对象而不是DataSet。仅在下列情况需要使用DataSet对象：
一、当我们需要远程控制从数据存储非连接的数据，并需要将数据传递到应用程序的另一层或客户端应用程序时，存储这些数据以便在过程中或类似的场景中使用、编辑它们。在存储才、传输或访问多个表时（例如，多个DataTable对象），以及这些数据之间的关系时，我们需要使用DataSet对象。
一旦我们决定了要使用的数据存储机制，另一个重要的问题又接踵而至，即如何将数据从某地传输到另一地。这里，可能只有一套方案能满足将来的需求。随着时间的推移，毫无疑问，我们将越来越迫切地需要与其他系统和组织的借口，因此，一套标准的数据转换格式也就必不可少。现在我们的选择显然应该是XML。XML独立于平台、应用程序和操作系统，因此也就提供了最好的合作机会。而且通过现在或近期内可用的工具，我们可以根据需要将XML文档转化为任何其他格式的文档——通常是将非XML文档或数据转换为XML文档。
因此，如果数据的传输协议和格式是基于XML的，且可利用任何现有的或新的技术来进行数据存储和处理，那么我们正在所需要的是一种稳定、可靠且使用范围极广的技术，用其来连接各种类型的数据存储，并处理各种类型的数据。而.NET Framework中就提供了对关系型和XML型的数据访问技术的组合。我们可以使用.NET数据访问类来连接几乎所有类型的数据存储。而且，只要提取了数据，我们就可以随意将这些数据在XML和传统的关系型行集格式之间转换。事实上，microsoft公司的BizTalk Server和其他相似的系统几乎可以在所有类型的网络上处理数据传输，并确保以XML格式提交数据，或者将数据转换为其他格式，并将其他格式转换为它的格式。
如果DataSet对象被用作可以存储和传送非连接数据的包，我们就需要对结构以及DataSet的内容进行很好的控制。使用代码我们可以直接将数据硬编码到页面的，但是它们可以像以前那样由用户输入，或者通过处理从其他种类的数据存储收集的数据来实现——这也许是我们迄今为止使用的唯一的一种不支持基于SQL的数据访问的方法。
当我们从使用DataAdapter对象的Fill方法的现有数据源中填充DataSet中的表的时候，关于每列数据类型的信息都从数据源中自动收集起来，并添加到表中。而且，如果我们首先使用DataAdapter对象FillSchema方法，那么列的约束（即关键字，默认值，惟一值，无效值等等）也将添加到表中。所以，如果数据库的初始源表中的一列是不接受Null值的整型数据类型，则DataSet中的表也将具有相同的属性。
在执行存储过程的时候我们经常会使用“内联”以及“隐式”参数，我们知道这个过程是很容易编程的。而且还提供了更为简洁（因而更为快速）的代码。不过，一旦我们使用了两个以上的参数，或者需要使用返回参数来将结果从数据库返回到代码中，那么隐式技术就不那么使用了。这种技术的另一个局限性就是有些数据存储不支持它。为了得到一种更为普通的方法，我们可以显式地为每个存储过程都创建一个参数，并且在执行查询之前给这些参数赋值。
Command对象给出了可以包含多个Parameter对象的Parameters集合。每个Parameter对象都有一系列我们可以访问和设置的属性。当我们调用Command对象中的ExecutePeader、ExecuteNonQuery或者ExecuteScalar方法时，这些参数就会作为命令的一部分被发送到数据存储。
我们还要重复一个最先在数据库管理中学习的问题，我们以前曾经做过用新的XslTransform对象对XML或XSLT转换时很容易的。但是，那是我们用的是很基本的方法——通过制定这些文件的路径来将转换应用到两个磁盘文件（XML文档和样式表）。
当文档并不是一个磁盘文件时，我们可以用XslTransform对象来执行转换。这种情况在处理XML的应用程序中很可能出现，例如XML可能别一个XmlTextReader引用，或者可能存储在由web服务或业务组件返回的XmlDocument对象中，甚至可能有一个现有的XPathNavigator指向该XML的指针。另外，我们可能不需要将结果写成磁盘文件——而是要将他们作为一个String或StringBuilder对象。
DataTable对象给出了一系列事件，我们可以使用这些事件来监控对DataSet中表内容作的修改。在对列进行修改之前（允许取消这种修改），为正在被编辑的行中的某列引发ColumnChanging事件。ColumnChanged事件是在下面情况被激活的：列发生了修改，而且这种变化已经固定了下来。
还有些事件是把行为作为一个整体，而不是作为行中的一列而出现的。RowChanging和RowChanged事件是在表中的任何行的内容发生变化时出现的——前者是发生在对行进行修改之前（允许取消这种修改），而后者发生时，这种变化已经固定在表中了。
我们在完成创建DataSet，添加表和关系，用数据填充表，以及设置每列上的几个属性。但是还有待于考虑的一点是我们如何创建作为主键和外键的列。当我们打开页面，我们就会看到从数据存储的两个表中选择数据，并且用它们填充DataSet对象。这样就自动为列设置了适当的数据类型。但它并没有在DataSet中指定表中哪些列是主键，哪些列是外键。
很明显，我们可以在DataSet中内部创建各表之间的关系。接着可以再表中访问数据时使用这种关系从父记录导航到自子记录，以及返回父记录，这就像我们以前学过的那样，不过这样做并不改变表的结构，也不会对每个表指定哪些列是主键，哪些列是外键。所以，我们需要能够自己创建这些键，以前需要对每个列对象都设置属性值，现在则不同，为了定义主键和外键我们把他们创建为对象，并且复制列约束条件。这样做是因为主键和外键的组合可能不仅仅包含一列——例如我们数据库中BookPrices表的可能主键就是ISBN号和货币名的组合。没有哪一列的值在整个表中是独一无二的，只有若干列的组合才可能提供惟一的键值。不过ISBN列单独提供了到父表BookList的链接，故我们把它指定为BookPrices表中的一个外键。
在网站建设编码过程中，我们需要对数据存储进行简单的单行或多行更新，通常一起使用一个ADO Connect的对象或Command对象，和一个SQL语句或存储过程来实现。这对于向数据库中插入一行新纪录是非常有用的，例如响应用户提交对站点的反馈，或是每月电子邮件公司的注册。另外，对于删除一行或多行，或是更新行的值等操作，这个技术也是非常适用的。
在.NET Framework中，实用一个新的Command对象也可以实现同样的目的。SqlCommand对象只适用于SQL Server（TDS），而OleDbCommand对象则只适用于那些可以利用OLEDB提供者的数据存储。在网页的页面中我们使用一个SQL UPDATE语句对数据库中的一行进行修改，还可以使用数据库中的一个存储过程添加或删除现有的一行。这两种方法都可以对数据进行更新，但对数据源进行更新的一个简单的方法就是创建一个适当的SQL语句，然后使用一个Command对象对数据源运行该语句。在设计好页面后，我们打开页面可以看到，Page_Load事件处理程序中的代码就会创建一个SQL UPDATE语句，该语句的BookList表中对某个具体特定ISBN代码的名字进行修改，这样更新数据既操作简单，又快速。
大多数数据库系统和一些其他类型的数据存储的特点之一就是能够使用事务。简单说来，事务就是在网站建设编码中一系列全部完成或全部没完成的事件。不可能出现事务中的某些事件发生而另一些没有发生的折中情况。
事务这个名称来自于现实世界。例如在商店里买某样东西，我们用钱来交换售货员的货物。除非我们是受骗了，否则这个交易或者成功，两者皆大欢喜（也就是我们付钱并得到货物），或者交易失败，什么都没发生。不可能出现付了钱却没有得到货物，或是得到了货物却没付钱的情况。在这里我们来说两种类型的事务，数据库事务，数据库专用语句对事务加以控制。它是在数据库的内部执行的，通常事务语句是包含在数据库中的存储过程中的。基于连接的事务，控制事务的语句以及该事务的执行和管理都是在数据库之外实现的。通常这些都是执行SQL语句或存储过程的Connection对象的一个功能。
有时用户访问资源时的身份好像用了其他用户或其他名一样。一个例子就是当web页没有访问控制时，也就是说允许任何用户访问该页。实际上这是一种过分简化，因为windows从来不允许匿名访问。所有用户必须通过现有账号进行身份验证和授权。网站建设中对于HTML页、ASP页和以前版本中的组件而言，通过IUSR_machinename和IWAM_machinename这两个账户进行身份验证。当安装IIS时设置这些账户，并且自动添加到服务器上每个web站点的所有文件夹中。
如果我们允许匿名访问IIS中的资源，每个用户看起来都一样，我们将无法辨识用户，也不需要识别。当IIS接收到对允许匿名访问的web页或其他资源的请求时，它使用IUSR_machinename账户代表用户访问资源。如果他们请求的资源是一个使用COM或COM+组件的ASP页，该组件默认情况下用IWAM_machinename账户执行。
