在研究该主题时，我发现了这篇文章：Should you enforce constraints at the database level as well as the application level?
回答问题的人声称我们应该强制执行数据库约束，因为它“更容易，更完整，更灵活”。
我提出这个问题的原因是因为我最近在一个非常强大的系统中进行维护工作。由于业务规则发生变化，以前拥有CHAR(5)的数据列之一现在接受8个字符。这个表有许多依赖关系，不仅会影响数据库中的许多其他表，还会影响其他一些系统，因此将大小增加到CHAR(8)几乎是不可能的。
所以我的问题可以追溯到数据库设计 - 如果减少甚至消除数据库约束的需要，它会不会那么容易？如果上述情况发生，您所要做的就是更改前端或应用程序级别验证，以确保用户为该字段输入8个字符。
在我看来，我们应该最小化数据库约束，以预测未来数据结构的任何变化。你的想法是什么？
答案 0 :(得分：4)
维护100个表比100,000行代码更容易。通常，必须在许多应用程序中复制在应用程序中而不是在数据库中强制执行的约束。有时，这些应用程序甚至由不同的团队编写和维护。
当需求变化时保持所有这些变化同步是一场噩梦。涟漪效应甚至比您将五个字符字段更改为8个字符字段所概述的情况更糟。这就是数据库发明之前的事情。
话虽如此，在某些情况下，在应用程序中强制执行约束比在数据库中执行约束更好。甚至有些情况下，在两个地方强制执行约束都会更好。 （例如：非空约束）。
非常大的组织有时会维护一个数据字典，其中每个数据项都按照功能（包括约束）进行编目，定义和描述。在这种环境中，数据库实际上从字典中获取它们的数据定义。应用程序通常在预编译时执行相同的操作。
未来证明这样的安排仍然是一个挑战。
答案 1 :(得分：2)
我同意你的观点，应该避免像田地长度这样的限制，你永远不知道你的生意会如何改变。现在硬件和硬件都很糟糕，实际上没有必要使用CHAR（8）来减少存储空间。
但是，对于标题详情信息表，not null constraints，duplicate check和foreignkey constraints这些限制条件最好保留。它就像你的数据整合的守门员。
答案 2 :(得分：1)
数据库系统提供了许多好处，其中最重要的是（物理）data independence。数据独立性可以定义为应用程序在数据物理存储和访问方式上的变化，这个概念与数据模型设计和数据约束是基本的规范化角色密切相关。
数据库共享是应用程序集成模式之一，广泛用于独立应用程序之间。权衡将试图在所有应用程序中或在数据库内以中心方式传播数据完整性代码。
最大限度地减少数据库约束将最大限度地减少多年来由各种非常聪明的人开发的各种众所周知的成熟技术的使用。
作为脚注：
此表有许多依赖项，也会影响许多其他依赖项 表格不仅存在于数据库中，还存在于其他一些系统中
除了这种气味冗余之外，至少它显示了变化的副作用。想想何时必须通过代码审查找到副作用！
应用程序到来，应用程序仍然存在但数据仍然存在。