database - 数据库：大量外键

Question

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

其中一张表称为车辆，它只有一列包含车辆的 ID，并且它是主键。

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

我开始担心有这么多外键只指向一张表是否正常。

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

PS 有些关系是一对一的，有些是一对多的。

Answer 1

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

有什么选择？在 70 个表格中复制该车辆信息？这对我来说听起来不是一个好主意。

我不理解只有 ID 的单列车辆表。需要的车辆是否没有有意义的属性？车辆识别号？制作？模型？年？车库地址？我不喜欢这种声音。我会仅在此基础上质疑您的其余设计。

70张桌子不是一个大数目。

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

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

Answer 2

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

如果“现实世界”中的关系是正确的，即 70 个表中的每一个表中的每一行确实包含与一辆车有关的信息，那么这样做本身并没有错，尽管人们通常希望找到更多比“车辆”表中的单个主键值。

从纯粹的数据库规范化的角度来看，有人可能会争辩说，在涉及一对一表映射的情况下，每个表的列都可以移动到“车辆”表中。但是，如果您在其他一对一表中有大量列（假设任何人有兴趣直接查看表......它可能无论如何，所有这些都被您的应用程序的前端抽象出来，或者您可以通过使用简单的查询有选择地检查具有大量列的单个表）。

再说一次，有时有很好的性能原因来选择性地对数据库的部分进行非规范化。

这完全取决于您要实现的目标。对规范化和非规范化有很好的理论理解可能是一个很好的起点。

我通常采用的方法是，对于 RDBMS，我默认进行标准化，除非有充分的理由不这样做。在将非规范化作为提高性能的一种选择之前，我会先正确地索引并构建查询。

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

Answer 3

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

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

如果这会产生一个像您所拥有的那样的数据库模式，那么对于大多数目的来说它可能已经足够好了。如果没有，请考虑更改您的架构。