sql - 为什么没有主键的表是一个坏主意？

Question

我对数据建模非常陌生，根据微软的 Entity Framework ，没有主键的表是不允许的，这显然是一个坏主意。我试图找出为什么这是一个坏主意，以及如何修复我的模型，这样我就不会出现这个漏洞。

我当前的模型中有 4 个表:User、City、HelloCity 和 RateCity。它的模型如图所示。这个想法是，许多用户可以访问许多城市，并且一个用户只能对一个城市评价一次，但可以多次向一个城市打招呼。因此，我没有在HelloCity表中进行PK。

关于如何更改此设置以符合最佳实践以及为什么这从一开始就违背最佳实践的任何见解？

Answer 1

此回复主要基于意见/经验，因此我将列出一些我想到的原因。请注意，这并不详尽。

以下是您应该使用主键 (PK) 的一些原因:

1. 它们使您能够唯一地标识表中的给定行，以确保不存在重复项。
2. RDBMS 会为您强制执行此约束，因此您无需在插入之前编写额外的代码来检查重复项，从而避免全表扫描，这意味着性能会更好。
3. PK 允许您创建外键 (FK)，以 RDBMS“感知”它们的方式创建表之间的关系。如果没有 PK/FK，这种关系只存在于程序员的头脑中，引用的表可能有一行“PK”被删除，而另一个带有“FK”的表仍然认为“PK”存在。这很糟糕，这导致了下一点。
4. 它允许 RDBMS 强制执行完整性约束。是TableA.id引用者TableB.table_a_id ？如果TableB.table_a_id = 5那么，您保证与id = 5有一行在TableA 。保持数据完整性和一致性，这很好。
5. 它允许 RDBMS 执行更快的搜索，因为 PK 字段已建立索引，这意味着在搜索某些内容(例如二进制文件)时，表不需要检查其所有行在树结构上搜索)。

在我看来，不进行 PK 可能是合法的(即 RDBMS 会允许)，但不道德(即你不应该这样做)。我认为您需要有非常好的/强有力的理由来争论不在数据库表中使用 PK(我仍然认为它们有争议)，但基于您当前的经验水平(也就是说，你说你是“数据建模新手”)，我想说这还不足以尝试证明缺乏 PK 的合理性。

还有更多原因，但我希望这足以让您解决这个问题。

就你的M:M而言如果关系继续下去，您需要创建一个新表，称为关联表，并在其中创建一个复合 PK，该 PK 是其他 2 个表的 2 个 PK 的组合。

换句话说，如果有 M:M表之间的关系 A和B ，然后我们创建一个表C有一个 1:M与两个表的关系 A和B 。 “以图形方式”，它看起来类似于:

+---+ 1  M +---+ M  1 +---+
| A |------| C |------| B |
+---+      +---+      +---+

与 C表PK有点像这样:

+-----+
|  C  |
+-----+
| id  |  <-- C.id = A.id + B.id (i.e. combined/concatenated, not addition!)
+-----+

或者像这样:

+-------+
|   C   |
+-------+
| a_id  |  <--|
+-------+     +-- composite PK columns instead
| b_id  |  <--|   of concatenation (recommended)
+-------+