数据库：大量的外键

Question

我有一个关于gps系统的mysql数据库。它有大约70个表。

其中一个表名为车辆，其中只有一列包含车辆ID，而且它是主键。

其余表包含一个名为 vehicleId 的列，它们都是外键。

如果有这么多外键指向一个表是正常的，我开始担心。

实际上这是我的问题： 70个外键只指向一个主键是否正确？

P.S。一些关系是一对一的，其中一些是一对多的。

Answer 1

你引用的问题并不一定意味着你有问题，但这并不意味着这是一个好的设计。

有什么替代方案？在70张桌子上复制车辆信息？这对我来说听起来不是一个好主意。

我不明白车辆表只有一列只有ID。关于需要的车辆是否没有有意义的属性？ VIN？使？模型？年？车库地址？我不喜欢这个声音。我会在此基础上质疑你的其余设计。

70个表不是一个很大的数字。

你到底是什么问题？您是否因为JOIN过多而发现性能问题？ JOIN中七个或更少的表是通常的经验法则。

我担心每个表都以这种方式耦合。它具有与太耦合的对象模型相同的问题。你没有提供足够的关于你的问题的详细信息来说明你到达这个地方的原因，但我希望有一个更好的设计来拥有与自然相关的表格集群。每个人都在和每个人交谈，感觉它可能是一张大桌子。一点也不好。

Answer 2

首先，我假设你正在使用某种关系数据库管理系统，可能是SQL系统。

如果“真实世界”中的关系是正确的，即70个表中每个表中的每一行都真正保存了一辆车的相关信息数据，那么这样做本身并没有错，尽管人们通常会期待在'vehicles'表中找到多个主键值。

从纯粹数据库Normalization的角度来看，人们可能会争辩说，在涉及一对一表映射的情况下，每个表的列可以移动到'vehicles'表中。但是，如果你在其他一对一表中有大量的列，那么对于试图阅读表的人来说，这听起来似乎很笨拙（假设任何人都有兴趣直接查看表...它可能好吧，所有这些都被前端为您的应用程序抽象出来，或者您通过使用简单查询选择性地检查具有大量列的单个表。）

然后，有时候选择Denormalize部分数据库会有很好的性能原因。

这一切都取决于你想要实现的目标。对归一化和非规范化的理解很好，可能是一个很好的起点。

我通常采用的方法是，对于RDBMS，我默认情况下进行规范化，除非有充分的理由不这样做。在我将Denormalization作为提高性能的选项之前，我会考虑正确编制索引并构建查询。

我认为，就您而言，根据所提供的信息，我想将列表从一对一表格移到“车辆”表格上。

Answer 3

如果您有一个好的ER模型，它可以识别管理存储在数据库中的所有值的实体，关系和属性。为每个实体创建一个表，其中包含一个标识列，该列对于每个实体实例具有唯一值。

为关系添加外键。对于多对多关系，添加表以保存外键对（或三元组等）。对于一对一关系，请考虑将两个实体表合并为一个。如果关系是可选的，您可能希望将表保持独立，但使用以下标记中概述的技术：shared-primary-key

如果这会产生类似于你所拥有的数据库模式，那么它对于大多数用途来说可能已经足够了。如果没有，请考虑更改您的架构。