Database design 在数据库中使用默认值是一种不好的做法吗？

代码不应该处理默认值而不是数据库吗？

这取决于您对“默认”值的看法。这样想：如果更改默认值，会发生什么？如果现有值应该更新，那么默认值应该只在程序代码中，但是如果现有值应该保留，那么您应该将默认值存储在数据库中。

我通常认为代码应该考虑默认值。这将有助于保持你的数据库精益和平均。尽管如此，如果您的数据库似乎有过多的空字段，您可能需要重新考虑设计

例子

---

假设您有一个包含一百万行或更多行的表。在这个表中，您有一个datetime列，该列大约占5%的时间。随着时间的推移，通过存储空默认值所节省的空间量将使必要的默认检查变得非常值得。

在数据库中可以执行的任何操作通常都更加健壮。如果您处理的默认值仅在您的应用程序中未指定任何值时才会使用，并且有人试图通过应用程序以外的其他方式连接到您的数据库（相信我，用户将尝试使用Excel或其他工具连接）-然后数据库是完全开放的，用户可能会插入蹩脚的数据

引用完整性和检查约束也是如此。我相信，如果您尝试在数据库上设置尽可能多的约束，您会过得更好，那么无论用户如何连接，如果他没有向您发送任何内容，您都可以设置合理的默认值

不要让应用程序处理您的检查-将其留给数据库

---

此外，如果您不必指定所有“明显”的默认值，例如“LastChangedOn”日期列的“getdate（）”等，那么它将使SQL insert语句变得更加精简和有意义。

恰恰相反。数据库应始终提供默认值，以确保添加的记录有效且有意义。请记住，在编写应用程序时，您无法预测最终将向数据库添加记录的代码

这并不是说您可能没有由应用程序指定的第二级默认数据，这取决于创建数据时的应用程序状态

---

因此，假设您有一个员工状态代码，可以是“p”（propect）、“A”（active）、“T”（terminated）或“R”（retired）。例如，您应该在数据库级别指定用户是以“P”还是“A”的身份进入系统（或者可能是未分配的第五个代码）。但是您的应用程序可以并且应该要求用户创建雇员记录来从一组单选按钮中选择一个选项，并在插入记录时使用该值。

您可能需要考虑更改默认值所需的内容。如果您的应用程序在内部，那么更改可能并不困难，但如果它在您的客户站点上，那么更改数据库可能是一个非常困难的过程。如果您有成百上千的客户机，并且您需要说服他们的DBA允许您使用update process SA访问数据库，您将后悔将任何应用程序逻辑放入数据库中（包括默认值）。

与大多数“代码与数据库”参数一样，这取决于具体情况

如果您的数据库（或表）将被许多不同的客户（即不密切合作的团队）访问，那么数据库应该自我保护。理想情况下，一切都应该通过存储过程来完成

---

如果单个应用程序可以访问数据库，则该应用程序可以包含业务逻辑。在这种情况下，所有操作都应该由一个应用程序完成，该应用程序可以访问数据库。

代码默认值更容易进行单元测试

代码默认值支持多种场景。DB列默认值是一刀切的。例如，DB列默认值可能因客户类型而异

DB列默认对于维护开发人员来说常常是不透明的，因为它们远离插入语句，通常在中间层代码、存储过程等。缺省情况的存在或不存在可能是令人惊讶的，无论哪种方式。 DB column defaults保护数据库不受那些懒得填写默认值（这是一种数据损坏形式）的客户机的影响

客户机开发人员可以颠覆这两种默认设置。在中间层使用缺陷缺省设置给开发人员设置障碍更为容易。好的，没有数据库允许您要求字段在插入时采用默认值。（编辑：触发器可以强制执行此操作，但您必须将默认值复制到触发器，并且触发器将用默认值覆盖任何插入的值）例如，这可能会影响人们用于未知但未来日期或未知但过去日期的各种令牌，或者如果他们使用GETDATE（）可能会影响其中包括时间，或者如果他们使用带有年、月、日和无时间的默认日期

---

我建议确保默认值存在于数据库中有意义的地方，但不要实际使用它们。DB默认值应该是最后的默认值，并且默认值应该固定在中间层（即存储过程，数据访问层）。DB列默认值类似于异常处理程序——当有人意外忘记提供值时，应该使用什么值来防止数据损坏？

如果您关心数据完整性（如果您不关心，为什么要有数据库？），则需要在其所属的数据库中使用默认值。仅在代码中这样做是不负责任的。数据从应用程序代码以外的其他来源进入数据库

数据库旨在记录事实的断言

允许用户做出不完整的断言，并让dbms对不完整的部分进行无声的假设，这显然是不好的

如果您想要健壮、可靠的系统