我对数据建模非常陌生，根据微软的实体框架，不允许使用没有主键的表，这显然是一个坏主意。我试图找出为什么这是一个坏主意，以及如何修复我的模型，这样我就不会出现这个漏洞。
我当前的模型中有 4 个表：User、City、HelloCity 和 RateCity。它的模型如图所示。这个想法是，许多用户可以访问许多城市，并且一个用户只能对一个城市评价一次，但可以多次向一个城市打招呼。为此，我没有在HelloCity表中进行PK。
关于如何改变它以符合最佳实践的任何见解，以及为什么这一开始就违背最佳实践？
这个回答主要是基于意见/经验，所以我将列出一些我想到的原因。请注意，这并不详尽。
以下是您的一些原因should使用主键 (PK)：
- 它们使您能够唯一地标识表中的给定行，以确保不存在重复项。
- RDBMS 为您强制执行此约束，因此您不必在插入之前编写额外的代码来检查重复项，从而避免全表扫描，这意味着这里的性能更好。
- PK 允许您创建外键 (FK)，以 RDBMS“感知”它们的方式创建表之间的关系。如果没有 PK/FK，这种关系只存在于程序员的头脑中，引用的表可能有一行“PK”被删除，而另一个带有“FK”的表仍然认为“PK”存在。这很糟糕，这导致了下一点。
- 它允许 RDBMS 强制执行完整性约束。是
TableA.id引用者TableB.table_a_id? If TableB.table_a_id = 5那么，你就是保证与 吵架id = 5 in TableA。保持数据完整性和一致性，这很好。
- 它允许 RDBMS 执行更快的搜索，因为 PK 字段已建立索引，这意味着表不需要具有all在搜索某些内容时检查其行数（例如，在树结构上进行二分搜索）。
在我看来，notPK可能是legal（即 RDBMS 会让你），但它不是moral（即你不应该这样做）。我认为你需要有非常好的/强有力的理由来争论not在数据库表中使用 PK（我仍然认为它们有争议），但根据您当前的经验水平（即您说您是“数据建模新手”），我认为这还不够试图证明缺乏PK是合理的。
还有更多原因，但我希望这足以让您解决这个问题。
就你而言M:M关系走，你需要创建一个新表，称为联想性的表，以及其中的复合 PK，该 PK 是其他 2 个表的 2 个 PK 的组合。
换句话说，如果有一个M:M表之间的关系A and B，然后我们创建一个表C有一个1:M与两个表的关系A and 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)
+-------+
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
