Closed. This question is opinion-based。它当前不接受答案。
想改善这个问题吗?更新问题,以便editing this post用事实和引用来回答。
5年前关闭。
Improve this question
在研究该主题时,我遇到了这篇文章:Should you enforce constraints at the database level as well as the application level?
回答问题的人声称,我们应该强制执行数据库约束,因为它“更轻松,更完整,更灵活”。
之所以提出这个问题,是因为我最近在一个非常强大的系统中进行了维护工作。由于业务规则的更改,用于
所以我的问题回到数据库设计上,如果您减少甚至消除数据库约束的需求,难道不是那么容易吗?如果发生上述情况,您要做的就是更改前端或应用程序级别的验证,以确保用户为该字段输入8个字符。
我认为,我们应该最大程度地减少数据库约束,以预期将来数据结构中的任何更改。你在想什么
想改善这个问题吗?更新问题,以便editing this post用事实和引用来回答。
5年前关闭。
Improve this question
在研究该主题时,我遇到了这篇文章:Should you enforce constraints at the database level as well as the application level?
回答问题的人声称,我们应该强制执行数据库约束,因为它“更轻松,更完整,更灵活”。
之所以提出这个问题,是因为我最近在一个非常强大的系统中进行了维护工作。由于业务规则的更改,用于
CHAR(5)
的数据列之一现在可以接受8个字符。该表具有许多依赖性,并且不仅会影响数据库中的许多其他表,还会影响其他一些系统,因此从字面上不可能增加CHAR(8)
的大小。所以我的问题回到数据库设计上,如果您减少甚至消除数据库约束的需求,难道不是那么容易吗?如果发生上述情况,您要做的就是更改前端或应用程序级别的验证,以确保用户为该字段输入8个字符。
我认为,我们应该最大程度地减少数据库约束,以预期将来数据结构中的任何更改。你在想什么
最佳答案
维护100个表要比100,000行代码容易。通常,必须在许多应用程序中复制在应用程序中但不在数据库中强制执行的约束。有时,这些应用程序甚至是由不同的团队编写和维护的。
当需求变化是一场噩梦时,使所有这些变化保持同步。波纹效果甚至比您概述的将5个字符字段更改为8个字符字段的情况更糟。这是在发明数据库之前完成工作的方式。
话虽如此,在某些情况下,在应用程序中强制约束比在数据库中强制约束更好。甚至在某些情况下,最好在两个地方都实施约束。 (示例:非null约束)。
大型组织有时会维护一个数据字典,其中每个数据项都根据功能(包括约束)进行分类,定义和描述。在这种环境中,数据库实际上是从字典中获取其数据定义的。应用程序通常在预编译时执行相同的操作。
future 证明这种安排仍然是一个挑战。