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

Question

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

注意：现在存在的Counries，TrafficTypes和People可以全部由Id和Name列表示，但将来可能还有其他字段。也许我所追求的是某种类似于继承的技术？

以下是我所得到的图表：

Answer 1

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

您的数据库中的表数是否有问题？

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

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

Answer 2

关闭蝙蝠，我会在单独的桌子上保持单独的内容/物体/（汽车与动物）。

此类内容重叠属性的可能性最小。

事情是，一旦这些entites开始在你的系统中发展，你会发现一个表将有数百个列，每个实体填充单个列。

Answer 3

我没有看到继承如何适用于您的案例。但是，如果您对继承感兴趣，因为它适用于SQL表或关系，这里有一些要查找的内容：

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

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

Answer 4

别担心。你做对了。

在高度规范化的架构中，您将拥有大量几乎完全相同的表。

正如其他人所说的那样，你开始考虑的事情（多项事物的通用表格）是一个非常糟糕的主意，并且有许多缺点。

最大的缺点是，在维护数据完整性方面，您的关系无用。没有什么可以阻止某人分配一个TrafficTypeId所在的CountryCode，依此类推。

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

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