让一个中型业务应用程序绑定到一个数据库。此应用程序有许多影响多个表的业务规则。以这个简单的为例：
Person, Customer,的表ProspectiveCustomer，每个表都有一个“活动”标志此类规则过于复杂，无法由数据库触发器强制执行，并且根据设计选择，没有集中式代码来完成这项肮脏的工作。然后总是有可能一个错误将数据库设置为不一致的状态，正如我们每天在测试时注意到的那样。
由于我担心这种情况在生产中未被发现，我想知道编写一个检查数据库状态并报告任何不一致的脚本是否是个好主意。除了一些活动记录之外，这既有助于发现生产错误，也有助于在需要时修复数据库。
这种方法的唯一缺点是那些自测脚本的额外开发时间（在我的情况下不可忽略）。我错过了一些基本的东西吗？
此外，如果编写了这些自测，它们在测试活动中也会非常有用，从而最大限度地减少开发它们的额外工作量。
如果您想在数据库级别执行此操作，您可能需要考虑使用检查约束。
您可以在检查约束中执行多少操作可能会受到您使用的 RDBMS 的限制。
此线程中 SQL Server 中的复杂检查约束示例：http: //social.msdn.microsoft.com/Forums/en/sqldocumentation/thread/1d4cf16b-9b37-4eb5-b66b-a428487f42c9
（编辑：最好在应用程序级别强制执行此操作，这可能是您的选择，也可能不是）
理想情况下，您测试处理数据的应用程序以确保它们遵守业务规则 - 如果您可以捕获错误更改的数据，则更容易找出正在发生的事情，而不是查找不一致的记录。测试驱动开发在这方面确实有帮助。
其次，再次，理想情况下，您以一种不会发生这种不一致的方式对数据库进行建模 - 在您给出的示例中，通过将“状态”字段放在“人员”记录中，而不是客户或潜在客户桌子。
当然，理想世界是不存在的。
这就是为什么开发“防御性编程”概念的原因。许多语言都支持断言，可以让您保护您的应用免受这种不一致数据的影响——在我看来，这是一项巨大的投资，因为它迫使您将业务规则和假设转化为代码，并处理这些假设的可能性在没有进一步破坏的情况下是错误的——例如，如果你正在为这个系统编写一个发票应用程序，那么如果“person”、“customer”和“prospect”表不同步，那就不好了；然后允许开具发票通常要糟糕得多。将断言放入您的代码为您提供了一种结构化的处理方式。
我工作过的许多业务系统都包含常规（每晚）数据库脚本来检查数据的有效性——在许多情况下，我们有一个规则，即我们检测到的任何数据错误都会在每晚批处理中转换为新的检查，以便该系统随着时间的推移而增加。