何处放置默认值和唯一约束，代码或SQL服务器？

Question

我们正在设计一个新的数据库，我希望在某些地方输入一些东西，比如默认值。有3种情况：

1：新值，created_date字段。在插入时该列是否应该有默认值？

2：更新后的值，updated_date fiels。我一直在想实现一个触发器，将其设置为getdate（），其他选项在代码中。

3：国家表与country_name，我们应该直接在表上执行一个唯一的约束，或确保代码这样做吗？

并留下了一些话题，但我们在每个表中引用了一个updated_by和created_by（int），它引用了用户表中的user_id。这是否值得实施这个fk。所有表的限制？

Answer 1

1. CREATED_DATE，updated_date：如果这些纯属审计列，显示所做的更改以及由谁 - 触发器是合适的。如果你的数据模型依赖于这些（也许最近updated_date的记录被认为是最新的），那么你的应用程序应该这样做。然后，您的应用程序可以决定应该使用的当前时间，而不是根据服务器的当前时钟设置将其硬编码到架构中，即“最后插入的记录”。

2. 国家表：是的，使用唯一的约束。没有它，你的数据（以及你的查询）就没有意义了......你会得到意想不到的连接匹配，并且你将无法执行参照完整性。然后，您的应用程序可以可靠地依赖于它的唯一命名（例如，通过将它们存储在SortedList中）。

3. 外键用户表是的。如果首先保存数据是值得的，那么确保它是有效的是值得的。

Answer 2

我的最佳做法：

• 对于创建/最后更新日期，它 取决于如果你要使用 他们为你的业务逻辑 的一部分 - 如果他们只负责审核，在数据库上使用时间戳。如果 有任何机会，你可能想要 公开他们的业务属性， 他们应该在代码中分配。

• 唯一约束 - 我在数据库和代码中实现它们。这是数据库备份验证规则的一个例子，在两个地方定义它们并没有什么不好。代码定义应该捕获并处理它们，但是在代码无法捕捉某些东西的情况下，您希望具有约束的安全网络保持数据不被破坏。

Answer 3

约束条件必须至少放在数据库中。如果您必须在代码中复制它们（或从数据库中推断出它们）以提供更好的用户体验，那么就这样做吧。

数据库必须一致。我浪费了很多时间来追踪由于“无效数据”造成的问题。

这些都通过添加适当的约束和解决任何应用程序创建无效数据来解决。我宁愿有10张票，因为有人不能保存发票（易于追踪），而不是一张票，因为某种程度上报告得到了一个奇怪的值，这个值来自不良的发票数据。

Answer 4

尽可能地放在数据库中。如果有必要，您仍然可以从应用程序中操作/查看，但是这对数据完整性和将来的应用程序版本都有帮助（即，您不必在路上复制“Web应用程序”版本的逻辑）。