<分区>
在研究该主题时，我看到了这篇文章:Should you enforce constraints at the database level as well as the application level?
回答该问题的人声称我们应该强制执行数据库约束，因为它“更容易、完整、灵活”。
我提出这个问题的原因是因为我最近在一个非常健壮的系统中进行维护工作。由于业务规则发生变化，其中一个数据列曾经有 CHAR(5) 现在接受 8 个字符。这个表有很多依赖关系，还会影响数据库中的许多其他表，还会影响一些其他系统，因此将大小增加到 CHAR(8) 实际上是不可能的。
所以我的问题又回到了数据库设计——如果你减少甚至消除数据库约束的需要，不是会容易得多吗？如果发生上述情况，您所要做的就是更改前端或应用程序级别的验证，以确保用户在该字段中输入 8 个字符。
在我看来，我们应该尽量减少数据库约束，以预测 future 数据结构的任何变化。你的想法是什么？
最佳答案
维护 100 个表比维护 100,000 行代码更容易。通常，必须在许多应用程序之间复制在应用程序中而非数据库中强制执行的约束。有时，这些应用程序甚至由不同的团队编写和维护。
当需求发生变化时，让所有这些变化保持同步是一场噩梦。涟漪效应甚至比您概述的将五个字符字段更改为 8 个字符字段的情况还要糟糕。这就是数据库发明之前的做法。
话虽如此，但在某些情况下，在应用程序中实现约束要比在数据库中更好。甚至在某些情况下，最好在两个地方都强制执行约束。 (示例:非空约束)。
非常大的组织有时会维护一个数据字典，其中每个数据项都根据特征(包括约束)进行分类、定义和描述。在这种环境下，数据库实际上是从字典中获取数据定义的。应用程序做同样的事情，通常是在预编译时。
future 证明这种安排仍然是一个挑战。
关于数据库约束与应用程序级别验证，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26851291/