数据库：大量的外键

我有一个关于GPS系统的MySQL数据库。它有大约70个桌子。数据库：大量的外键

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

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

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

其实这是我的问题：是否有70个外键仅指向一个主键？

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

来源

2013-03-09 Joro Seksa

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

如果“现实世界”中的关系是正确的，也就是说，70张表中的每一行中的每一行都确实包含与一辆车有关的信息的数据，那么这样做本身没有任何问题，尽管通常可以期望在“车辆”表中找到多个主键值。

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

然后再次，有时有良好的性能原因选择Denormalize数据库的一部分。

这一切都取决于你想要达到的目标。规范化和反规范化的理论理解可能是一个很好的开始。

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

我认为，就您的情况而言，我所提供的信息，我想将列从一对一的表移动到'车辆'表。

来源

2013-03-09 15:34:12 Holf

如果我在车辆表中移动该信息，它将变成超过50列。 – 2013-03-09 15:50:26

是的，这本身并不是问题。如果车辆真的有50个属性是一对一的，那就没问题。尽管如此，大量的列可能意味着还有一些还没有被梳理出来的一对多关系。但这取决于情况。 – Holf 2013-03-09 16:39:34

一些信息是关于金钱交易的，有时我需要给其他开发者读取表格，但是我的老板不希望他们看到关于金钱的细节，所以我认为在单独的表格中更好：） – 2013-03-09 16:55:25

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

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

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

70表是不是大量。

究竟是什么问题？你有没有发现性能是一个问题，因为过度的JOIN？ JOIN中的七个或更少的表格是通常的经验法则。

我担心每个表都以这种方式耦合在一起。它具有与耦合的对象模型相同的问题。你没有给出足够的关于你的问题的细节来说明你为什么到达这个地方，但我希望有一个更好的设计，可以有很多自然相关的表格。每个人都在和大家说话，感觉它可能是一张大桌子。一点都不好。

来源

2013-03-09 15:24:51 duffymo

这更像是一个心理问题，因为我开始担心它感觉不对。 – 2013-03-09 15:42:58

如果您有一个很好的ER模型来标识管理所有要存储在数据库中的值的实体，关系和属性。为每个实体创建一个表，并为每个实体实例指定一个唯一值。

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

如果这样会产生一个类似于您所拥有的数据库模式，那么它可能足够好大多数目的。如果不是，请考虑更改您的架构。

来源

2013-03-09 16:17:59

数据库：大量的外键

回答

相关问题