database-design - 多个多对多关系是否是糟糕设计的证据？

Question

大家好，

我一直在学习数据库和数据库设计，但我发现我仍然遇到一个我自己无法回答的问题。所以我向社区提出这个问题，希望有比我更多知识/经验的人来回答。

我的任务是开发一个数据库，该数据库跟踪整个船队的库存水平。

当前的设计为每艘船都有一个表格，其中列出了所有可能的部件(机械类型、部件号、制造商、序列号等)

这意味着一件机器或零件的细节可以被复制很多次(实际上有多少艘船就可以复制多少次)。

我一直在尝试根据自己学到的知识进行重新设计，我会提出如下设计方案:

[SHIP]
ID, Name, Class, Tonnage, Fleet, Superintendent etc.

[Machinery]
ID, Type, Make, Model etc. (Can have separate table for manufacturers and types if required)

[Part]
ID, Part number, Description, etc.

以上将是三个主要的表，现在开始变得困难。

每艘船可以有多个机械项目，每个机械项目可以出现在多艘船上(需要一个连接表)

每个机械项目可以有多个零件，每个零件可以属于多个机械项目(另一个连接表)

可能有成百上千个部分使连接表变得巨大。

此外，一旦您想跟踪库存，您就会查看另一个连接表

[Stock Level]
ShipID, PartID, Stock Level

另外，如果您想要最低库存(可以与 Stock Level 结合使用吗？)

[Min Stock]
ShipID, PartID, Min Stock

最后，如果您想要标准化数据库(即没有 Part No.1、Part No.2 或 Serial No.1、Serial No.2)

你需要有几张额外的 table

[Serial Numbers]
ShipID, MachineryID, Serial No

[Part Numbers]
PartID, Part Number

序列号可能是相当标准的，没有问题，但是 [part numbers] 至少需要与 [Parts] 表中一样多的记录。

map (尽我所能在没有图片的情况下表示，为简单起见省略了路口)

  <>V represent many 
  -| represent one

   -----< Serial Numbers
  |             V
  |             |
Ship >---< Machinery >---< Parts ---< Part Numbers
  V                          V
  |                          |
   ------ Stock Level -------

现在真正的问题是，我是否在基本设计原则中遗漏了一些可以消除如此巨大的联结表的内容，或者这种数据库是否可以预期。

此外，在零件编号等情况下，规范化需要一个具有至少相同数量记录的附加表，而不是原始表中的额外列，您以后会去规范化以提高查询速度吗？

任何关于外部资源(包括其他论坛、教程、书籍)的提示、技巧或指针将不胜感激。

欢迎所有答案，提前感谢您提供的任何帮助。

戴夫

Answer 1

首先，否:多对多关系并不是糟糕设计的指标。

其次，连接表总是大于它们正在连接的表。如果您有两个表，每个表有 100 条记录，则连接表最多可以有 10000 条记录。

但连接表只不过是整数对，当您为它们编制索引时，它们的速度会非常快。

编辑添加:

你评论了:

I kind of thought indexing was done by the DBMS

您可以告诉 DBMS 索引什么。之后，自动更新索引。

一些 DBMS 有一些工具，可以监控您的系统的运行情况，并就哪些索引将是有益的提供建议。

你的设计过程很好，所以你可能走在正确的轨道上。