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

Question

我是数据建模的新手,根据微软的实体框架,不允许没有主键的表,这显然是个坏主意.我试图找出为什么这是一个坏主意,以及如何修复我的模型,以便我没有这个洞.

我目前的模型中有4个表:User,City,HelloCity和RateCity.它的建模如图所示.这个想法是许多用户可以访问许多城市,用户只能对一个城市进行一次评级,但他们可以多次迎接一个城市.出于这个原因,我在HelloCity表中没有PK.

有关如何更改此信息以符合最佳做法的任何见解,以及为什么这会违反最佳做法？

Answer 1

这种反应主要是基于意见/经验的,所以我将列出一些想到的原因.请注意,这并非详尽无遗.

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

1. 它们允许您有一种方法来唯一标识表中的给定行,以确保没有重复项.
2. RDBMS为您强制执行此约束,因此您无需在插入之前编写其他代码来检查重复项,从而避免进行全表扫描,这意味着此处的性能更佳.
3. PK允许您创建外键(FK)以便以RDBMS"了解"它们的方式在表之间创建关系.没有PKs/FK,这种关系只存在于程序员的脑海里,被引用的表可能有一行删除了它的"PK",而另一个带有"FK"的表仍然认为存在"PK".这很糟糕,这导致了下一点.
4. 它允许RDBMS实施完整性约束.被TableA.id引用TableB.table_a_id？如果TableB.table_a_id = 5那么,你保证有一排id = 5在TableA.保持数据完整性和一致性,这很好.
5. 它允许RDBMS执行更快的搜索b/c 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!)
+-----+