让绑定到数据库的中型业务应用程序。该应用程序具有许多影响多个表的业务规则。以这个简单的例子为例：
数据库具有名为Person，Customer，ProspectiveCustomer的表，每个表均带有“活动”标志
一个人可以是客户和/或潜在客户
同一个人的客户和潜在客户不能同时处于活动状态
如果客户或潜在客户不活跃，则该人不能活跃
发票的问题和生命周期确定谁在激活或不激活
这样的规则太复杂了，无法由数据库触发器来强制执行，并且根据设计选择，没有集中的代码可以完成肮脏的工作。然后，就像我们每天在测试时注意到的那样，错误总是有可能将数据库设置为不一致的状态。
由于我担心生产中不会发现这种情况，因此我想知道编写一个检查数据库状态并报告任何不一致情况的脚本是否是一个好主意。连同一些活动日志记录，这将有助于发现生产错误并在需要时帮助修复数据库。
这种方法的唯一缺点是这些自测脚本需要额外的开发时间（在我的情况下不能忽略）。我缺少基本的东西吗？
同样，如果编写了这些自测，那么它们也将在测试活动中非常有用，从而最大程度地减少了开发它们的额外工作量。
最佳答案
理想情况下，您将测试处理数据的应用程序以确保它们遵守业务规则-如果可以捕获不正确的数据，而不是查找不一致的记录，则可以更轻松地确定正在发生的情况。测试驱动的开发在这方面确实有所帮助。
其次，同样，理想情况下，您应以不会发生这种不一致的方式对数据库进行建模-在您提供的示例中，将“状态”字段而不是客户或潜在客户放在“人员”记录中表。
当然，没有理想的世界。
这就是"defensive programming"概念被开发的原因。许多语言都支持assertions，可让您保护应用程序免受这种不一致的数据的侵害-在我看来，这是一笔巨大的投资，因为它迫使您将业务规则和假设编码为代码，并应对可能的情况。这些假设是错误的，没有进一步说明-例如，如果您正在为此系统编写发票应用程序，则“人”，“客户”和“潜在客户”表不同步是不好的；然后允许开具发票通常会更糟。将断言放入代码中可以为您提供结构化的处理方式。
我研究过的许多业务系统都包含常规（每晚）数据库脚本来检查数据的有效性-在许多情况下，我们有一个规则，即我们检测到的所有数据错误都会在每晚批处理中转换为新的检查，以便系统随着时间的推移而增加。
关于database - 应用程序是否应该对数据库进行自我测试，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14738099/