sql - 将具有多个多对多关系的模式重构为语义不同但结构相似的实体？

Question

我有一个具有许多多对多关系的模式，我看到的是许多相似的数据结构分布在具有不同名称的表中。我的直觉是，有一种更有效/更理想的方法可以实现相同的结果，但我不确定哪些替代方法属于合理的设计/最佳实践。

注意：国家、交通类型和人——它们现在存在——都可以用 Id 和 Name 列表示，但将来可能会有额外的字段。也许我追求的是某种类似于继承的技术？

这是我所拥有的图表：

Answer 1

不要把你认为相似的东西混为一谈；当您需要存储有关每个实体的更多信息时，它们可能会在以后出现分歧。

您的数据库中的表数量有问题吗？

您可能从面向对象的设计位置考虑问题，并认为您可以使用某种“父”表来表示公共部分 - 数据库不是这样工作的。

如果您不小心，您最终会得到一个MUCK或OTLT表。

Answer 2

马上，我会将单独的实体/对象/（汽车与动物）放在单独的桌子上。

此类实体重叠属性的机会充其量是微乎其微的。

问题是，一旦这些实体开始在您的系统中发展，您会发现单个表将包含数百个列，每个实体都填充单个列。

Answer 3

不用担心。你做对了。

在高度规范化的模式中，您将拥有大量几乎相同的表。

正如其他人所说，您开始考虑的（用于多种事物的通用表）是一个非常糟糕的主意，并且有很多缺点。

最大的缺点是，在维护数据完整性方面，您的关系变得毫无用处。没有什么可以阻止某人将 CountryCode 分配到应有 TrafficTypeId 的位置，等等。

另一个缺点是拥有一个较大的表可能会比许多较小的专用表性能更差。由于额外的，不必要的阻塞。

您可能仍想实现某种类型的继承概念，但最好在访问数据库的任何代码中完成。

Answer 4

我不明白继承如何适用于您的案件。但是如果你对继承感兴趣，因为它适用于 SQL 表或关系，这里有一些事情要查找：

在 ER 建模级别查找“ER 模型专业化”。这是扩展 ER 模型图“是 A”关系的方式。

在表设计级别，查找“类表继承”和“共享主键”以了解几种技术，它们一起使用，有点模仿 OOP 中继承为您所做的事情。您可能还想查找“单表继承”以获得更简单但可能更浪费的替代方案。