我是否需要审计表中的id列？

Question

我看到的许多表格设计都有一个id列作为主键。例如某些Logging表中的log_id，某些事件表中的event_id等等。此列不依赖于任何其他表中的任何其他列，并唯一标识该记录。从查找角度来看，用于查找信息的列通常是表中可以编制索引的其他列（status / event_type / etc等）。那么，需要有一个表示表中记录的id列？如果我要从日志表中删除这样的id列，而可能使用复合键我犯了什么罪？为什么在表中有这样一个唯一的id列是如此普遍的做法，否则该列不会在应用程序中使用？希望能听到专家的意见。 ：○

更新：谢谢大家的快速回复！首先，我想了解为什么在审计表等表格中使用代理键而不是复合键是如此常见的做法（还有其他示例，但试图保持对话的重点）。在这样的表中，我可以通过事件，用户ID和时间戳的组合轻松识别唯一记录。我在网上研究的大多数设计仍然使用诸如event_id之类的密钥。我想知道为什么会有这个真正的原因？事实上，这不意味着消耗不必要的db存储空间吗？

Answer 1

我区分了在我的数据模型中实现真实关系的表，以及仅用于临时，日志记录，审计跟踪等数据转储的表。

这些表没有自然键 - 即没有列的组合可以保证唯一，但重复有意义;并且甚至没有可以应用的理论，逻辑自然键。换句话说，根据数据的关系模型，它不是真正的关系。我们只是为了方便而使用桌子。

在极少数情况下，表根本不需要密钥 - 一个简单的例子是日志表，它只记录发生的事件。它只是被插入，并且基于时间戳（这不能保证唯一的方式）完成清除。如果不需要密钥或代理密钥，则没有参考约束，那么我将省略它。

但是一旦表格需要被应用程序引用 - 例如如果我们需要在别处引用特定记录 - 它现在是数据模型的一部分，我们需要将其视为一个关系 - 即它的自然键是什么。一旦确定，我们就可以决定是否需要代理密钥。

通常，我的模式中没有ID的唯一表是完全没有约束的表 - 即调试日志和审计跟踪（即记录表上的每个插入/更新/删除）。如果不是更多，其他所有内容都至少会获得一个唯一约束。

Answer 2

如果它只是一个审计表，我个人对复合键没有任何问题。你需要某种键，因为你可能会偶尔清除日志，然后用一把钥匙就可以选择。

复合键的邪恶代表主要是因为有些人使用实际业务值（SSN，出生日期等）来组成密钥，然后将它们扩散到与父级具有外键关系的相关表中。 p>

这种扩散使表格非规范化，加上这些值可以改变。怎么样？最常见的是因为它们首先输入错误，但我有一个客户由于以下其他原因而不得不更改SSN：

• 由于身份被盗，客户获得了新的SSN。
• “无证件”且使用假SSN的客户，然后变成“记录”并获得真正的SSN。
• 最重要的一个：所有SSN必须加密存储的行政命令。

幸运的是，根据我的建议（以及其他人的建议），他们没有将SSN用作主键的一部分，因此这些更改很容易。

避免复合键的另一个原因是：它们增加了JOIN的复杂性。但同样，使用审计日志，您可能不在乎。

最后，我想强调的是，我几乎100％的时间都使用ID类型的值，并且已经使用了十多年，所以这并不是我对复合键的矛盾。我倾向于避免它们，但在你的情况下，我认为这不是一件坏事。

Answer 3

复合键与ID具有相同的用途。如果这符合您的需求，那么您就不会犯罪。

但是，如果您发现您选择的复合键引入了冲突（当您预期一个或没有时，您将返回多个记录），那么您将需要重新评估您的复合键。

拥有一个保证唯一且不会重复使用的ID可以解决这个问题（以表格中的额外字段为代价）。

Answer 4

除了其他回复之外，我认为要记住的另一个问题是您需要考虑的唯一性。如果您需要复合键保持唯一，则有两种选择：1）将复合创建为PK或2）使用代理键（系统生成的数字）并在复合（自然键）上添加另一个约束，备用键。这有时会推动我使用它。 戴安