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

在许多用SQL Server实现的新的企业系统设计中，系统设计师需要在给数据结构和管理应用程序逻辑的定位上做出具有关键性意义的决定。SQL Server有它自己的编程语言（Transact-SQL，即TSQL），开发者可以用它来管理数据访问、代码事务逻辑和交易控制。

使用TSQL，开发者可以创建保存过程，在保存过程中用一段可重用、预编译而且拥有自己的许可设置的代码块来封装数据访问。数据库中每个表格都有一组叫做triggers的特殊的保存过程。当底层数据库发生特定的数据库事件（如Insert、Delete或者Update）时，trigger就被“触发”了。使用triggers，开发者就可以编写基于事件的事务逻辑，这样，给定表格的Insert、Delete和Update事件就可以驱动其它表格的变化。

既然有了这样的灵活性，那么我们为什么不尽可能用TSQL写更多的事物逻辑呢？

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

TSQL不仅可以作为单个应用程序的逻辑仓库，它也可以是一个访问相同数据的应用程序组的逻辑仓库——这有几个逻辑上的原因。通过对数据的集中处理和管理SQL server中数据的规则，你可以配置这样的安全体系——即应用程序在通过事务规则之前，不可以访问底层数据库。

这是大多数两层客户——服务器应用程序的常见数据库范例。该体系把所有的事务逻辑和数据访问交给后端的服务器而把丰富的表示逻辑交给客户端。客户管理事务过程和数据的视（view），但不在本地处理除显示之外的其它事务。如果把所有的事务逻辑放到中央仓库去，那么这个体系还有降低管理成本的潜力，但这会付出降低了可测性的代价。

我最近接触了一个客户，它花了数百个人月（一个人工作一个月的工作量）和数以千计的美元来设计一个非常复杂的、用TSQL管理所有应用程序逻辑的应用程序。尽管该体系非常精巧、在10到15个用户的情况下也运行良好，但是如果有20个用户，速度就非常慢。通过给SQL server增加处理器的方法，该系统可以允许60个用户同时使用。但是这距离100个用户的设计目标还有很大一段距离，这就使得该公司在Internet上开放该应用程序的计划无法实施下去。由于存储过程和trigger只能操作本地数据，该公司无法把该应用程序分解成多个SQL server以提高可测性。结果，该公司不得不大规模的修改它。

在应用程序逻辑中使用.NET类

上面那家公司在经过一段曲折后所发现的问题，大多数体系设计师在体系设计阶段都会重新认识到——应用程序逻辑包含在一组.NET类的n层体系可以增加该应用程序的灵活性和可测性。由于TSQL是一种以管理数据为主要目的的语言，因此它不够灵活，但是我们仍可以用TSQL编写出复杂的事务逻辑。