解析SQLServer数据体系和应用程序逻辑

在许多使用SQL Server实现的新企业系统设计中，系统设计人员需要对数据结构和管理应用程序逻辑的定位做出重要决策。SQL Server有自己的编程语言(Transact-SQL，TSQL)，开发人员可以使用它来管理数据访问、编码事务逻辑和事务控制。
使用TSQL，开发人员可以创建一个保存过程，在该过程中，一个可重用的、预编译的代码块及其自己的许可设置封装了数据访问。数据库中的每个表都有一组特殊的保存过程，称为触发器。当底层数据库中发生特定的数据库事件(如插入、删除或更新)时，触发器被“触发”。使用触发器，开发人员可以编写基于事件的事务逻辑，以便给定表的插入、删除和更新事件可以驱动其他表的更改。

有了这样的灵活性，我们为什么不尽可能多地写出TSQL的逻辑呢？

使用TSQL开发应用程序逻辑存储

TSQL不仅可以用作单个应用程序的逻辑仓库，还可以用于访问相同数据的一组应用程序——这有几个逻辑原因。通过SQL server中的集中式数据处理和数据管理规则，您可以配置这样一个安全系统，使应用程序在通过事务规则之前无法访问底层数据库。

这是大多数两层客户机-服务器应用程序的常见数据库范例。系统向后端服务器提供所有事务逻辑和数据访问，向客户端提供丰富的表示逻辑。客户管理交易过程和数据的视图，但除了本地显示外，不处理其他交易。如果把所有的交易逻辑都放到中心仓库，那么这个系统有降低管理成本的潜力，但是会付出降低可测试性的代价。

我最近联系了一个客户，他花费了数百个人工月(一个人一个月的工作量)和数千美元来设计一个非常复杂的应用程序，用TSQL管理所有的应用程序逻辑。虽然该系统非常精致，在10到15个用户的情况下工作良好，但如果有20个用户，速度就非常慢。通过向SQL server添加处理器，60个用户可以同时使用该系统。然而，这距离100个用户的设计目标还有很大距离，这使得该公司在互联网上开放应用的计划无法实现。由于存储过程和触发器只能操作本地数据，公司无法将应用程序分解成多个SQL server来提高可测试性。结果公司不得不大规模修改。

使用。应用程序逻辑中的. NET类

上述公司经过曲折过程发现的问题，在系统设计阶段会被大部分架构师重新认识——一套N层的系统所包含的应用逻辑。NET类可以增加应用程序的灵活性和可测试性。由于TSQL是一种主要目的是管理数据的语言，它不够灵活，但我们仍然可以用TSQL编写复杂的事务逻辑。

如果开发人员使用。NET框架，那么他们就可以在开发核心事务流程的时候，做出自己的语言选择。这种灵活性允许您在应用程序需求和开发语言或资源之间做出最合理的匹配。此外，如果开发得当，封装这些事务处理的对象可以在多台机器上运行，并共享同一个底层数据库服务器。无论TSQL事务逻辑如何，SQL server都可以处理大量并发请求。

行操作和集合操作。

在规划系统阶段判断使用行运算还是集合运算的指导思想之一是:如果使用TSQL，则使用集合运算，如果。NET使用，行操作使用。通过网络连接提供大量数据会影响应用程序的整体性能，因此尽可能使用服务器来处理它们是有意义的。但是，从内存和处理能力的角度来看，SQL Server的游标是一个非常昂贵的对象，因此创建一个指针来遍历集合中的所有记录并依次处理它们一般没有太大意义。

当您需要执行基于行的处理(涉及复杂的程序逻辑或CPU密集型操作)时，您应该从服务器查询这些行，并在中间层处理它们。

如果您想通过示例了解如何将数据访问逻辑封装到中间层对象中，请从MSDN下载数据访问应用程序模块。这是一个可复用的数据访问子系统，提供代码，你可以根据它编写自己的数据库或者特性应用的数据访问对象。

通过创建一个可重用的。NET应用程序框架来处理大部分应用程序逻辑，并使用基于TSQL的保存过程作为服务器端set操作的安全限制和机制，您可以创建一个兼具TSQL和。网。