命名复杂的对象覆盖

先前的SQL Server 时事通讯“命名SQL 对象”产生了很多正面共鸣。但是，有读者指出，这仅仅只覆盖了一些简单的例子，比如，在一个单表中的什么地方添加一个行。这篇文章将几少如何命名复杂的对象，比如一个存储进程如何通过多种方式影响多重表格。

我们假设我们有一个存储过程，它在有相关联系的层次表格上执行层叠删除。比如，删除一个用户并在Sales，SalesDetails, PurchaseOrders, 和 Payments表格中删除相关联的行。那么如何对这个对象命名？这里有另外一个例子：一个存储过程在两到三个表格中删除行，并添加相同的行到第二个数据库中的档案表格中。如何给他们命名？

在上个章节中，我提出了一个协定，叫做Object-Action.根据这个协定，我们可以注意到所有被这个存储过程影响的表格。但是，在复杂的应用程序中，那个方法可能会违反最大标识符长度规则。

复杂的进程通常包含一些特殊的商业进程；这个提供了更好的命名目录，它将比简单的连接表格名字更佳。这个进程引用了上面的CustomerDeleteCascade_ap并接受了一个参数@CustomerID。尽管没有详细定义所有被影响的表格，这个命名暗示了执行他的因果关系。只要注意数据库图表将会转达这个进程将要做什么，但是在这个进程中的引申备注将详细定义发生的任何细节。

遇到太便宜的熟制羊肉一定要在心中先打个问号 两个相同形式关心的是商业规则和商业对象。前者规则通过管理各种行为是否被允许的机构来定义。后者是复杂的对象，它们可能和数据库中的任何单独表格都不相应，但是更符合上述介绍的一些表格中的一些行的映射。在这种情况下，我建议更倾向于将对象作为根“表格”并遵循Object-Action规则。

关于商业规则和它们相应的进程，我提议命名规则应该基于商业规则和“_br”后缀，这个将迅速的识别在SQL对象的络位置。

命名复杂的SQL对象并不烦琐，但是这个规约对于你来说是一个成功的开始；它们同样可以保护大多数有价值的Object-Action命名规约：主要的对象按照字母排列，因此动作指示符将被执行。这个对象将比一个表格更复杂，并且这个动作将比一个简单的删除，插入或者更新更复杂。

这些名字不象Object-Action规则那样直接，但是，如果它们坚持原理，那么这些名字将会提供相等的脚注：每件你需要知道的事情都在进程的注释里。

本文作者：Arthur Fuller 从事数据库开发已经有20年. 他擅长应用开发 Access ADPs, Microsoft SQL 2000, MySQL,和 .NET.

：李宁

欢迎评论或投稿