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

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

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

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

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

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

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