具有双列主键的数据库表的最佳实践是什么？其中一列是可选的？

Question

在工作中，正在审查一个由三列组成的表：

1. 行ID（非空，整数）
2. 上下文ID（非空，整数）
3. 值（非空，可变字符）

总行数很少（小于100）。如果没有上下文ID，则Context Id当前设置为0。上下文ID是可选的。

主键是（行ID，上下文ID）

在这种情况下，提出了两个选择：

1. 保持原样

2. 将表格分为两个表格。当Context Id为0（行ID，值）时有一个表，当Context Id有值（行ID，上下文ID，值）时有一个表。

如果有大量行，那么我同意拆分表的决定。如果行数很少，那么将表格分开似乎有点矫枉过正。

在这种情况下，我会对人们推荐的内容感兴趣吗？总是将单个表分成两个表是否更好？

谢谢，

-Larry

Answer 1

首先，如果这是entity-attribute-value反模式，请避免这种情况。这个答案的其余部分假定它不是。

在决定你是否想要对某些东西（单个表格）或特定（两个表格）进行建模时，你需要考虑你的代码是否能够一般地处理事物或需要特殊情况。

是否需要特殊情况？

您的代码是否会对ContextId为0进行特殊处理？例如，您是否可以运行select WHERE ContextId=0然后继续以通用方式查看不同的上下文？是否有特殊逻辑只能用ContextId=0？您是否觉得需要在代码中表示此contextId的特殊常量？这个常数会出现在某些if语句中吗？

如果这些问题的答案通常是肯定的，那么创建单独的表格。如果不管怎样对待它，你就不会把这些东西放在一张桌子上。

根据你的问题，这是我的猜测。

或者这一切都是通用的吗？

如果ContextId为零被视为与整个代码中的所有其他上下文ID一样，那么无论如何都要将它放在与其他代码相同的表中。

<强>权衡

如果事情不那么明确，你需要做出权衡决定。您需要根据您对此信息的使用量是多少以及具体内容来进行此操作。我会偏向于创建两个表。

Answer 2

没有足够的信息来决定但是：
从数据库设计的角度来看，参加minimum side-effect changes，我更愿意在表中添加一个新列，称为ID和setting it as the Primary Key of the table，having a new unique key on (Row Id + Context Id)列。
背后的逻辑（Row Id + Context id）是您的应用程序逻辑，应用程序逻辑绑定到更改。
建议使用表的主键分隔业务标识符和逻辑。 任何字段都显示给最终用户，有被要求更改的风险，使维护和开发变得困难。
希望对你有所帮助。