哪个更好：约束还是 FK？对于状态列答案

【问题标题】：What's better: Constraint or FK? For a Status column哪个更好：约束还是 FK？对于状态列
【发布时间】：2011-12-29 11:58:20
【问题描述】：

我有一个使用 Entity Framework 4 和 SQL Server 2008 R2 的 .NET 应用程序，其中所有数据访问层都将由 EF4 管理。

我有一个金融交易表：交易，其中有一列状态，可能的值是：已打开、已发布、已验证、已关闭。该表将一直被访问以进行插入、更新和读取。我需要在这张桌子上达到更好的性能。

标准的解决方案是用Id(int)、Name(varchar)创建一个TransactionStatuses，并在Transactions和TransactionStatuses之间建立关系.

但现在，我正在考虑另一种解决方案：仅创建具有列 Status(int) 的 Transactions 表，并创建一个 Status 仅接受 1、2、3、4 的约束。并且，在我的应用程序代码上创建一个枚举，其中 Opened = 1、Release = 2、Verified = 3 和 Closed = 4。

从性能角度来看，第二种解决方案是更好的选择吗？

【问题讨论】：

您是否希望在查询中返回字符串名称？或者提供任何允许编辑状态名称或添加新名称的管理界面？
不，Db 中的名称仅供参考。管理界面只会使用状态，不会编辑或新建。

标签： .net sql-server performance sql-server-2008 entity-framework-4

【解决方案1】：

两者都会很快；约束也许更容易检查，但数据库经过高度优化，可以非常快速地检查 FK 违规。

鉴于两者，从维护的角度来看，我更喜欢 FK 选项

通过 DML 添加新的状态行真的很容易，而更改（可以说）更难部署的约束，需要 DDL
如果需要，您可以从其他元数据列中受益 - 即代码附带的描述，可能还有软删除日期（用于从 UI 中删除，而不会使旧数据无效）

如果数据永远不会发生变化，那么任何一种方法都是完全可行的，不会有任何偏见。

【讨论】：

【解决方案2】：

如果您的 TransactionStatuses 是不可变的，并且您只需要一个值（在这种情况下，是与枚举值相关的整数），那么可以，我建议您忘记额外的 TransactionStatuses 表。

另一方面，如果您计划将其他信息附加到与您的业务层相关的状态，或者您计划让人们自定义状态，那么它应该是一个实体，因此应该有一个表格。

【讨论】：