多个很多关系是不良设计的证据吗？

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

此外,如果您想要最低库存(可以与库存水平相结合？)

[Min Stock]
ShipID, PartID, Min Stock

最后,如果您正在寻找标准化数据库(即没有第1部分,第2部分或序列号1,序列号2)

你需要一些额外的桌子

[Serial Numbers]
ShipID, MachineryID, Serial No

[Part Numbers]
PartID, Part Number

序列号可能是相当标准的并且没有问题,但是[部件号]将至少需要与[部件]表中的记录一样多的记录.

地图(尽管我可以代表没有图片,但为简单起见省略了交叉点)

  <>V represent many 
  -| represent one

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

现在真正的问题是我在基本设计原则中遗漏了哪些东西会消除这种巨大的连接表,或者这种数据库是否会出现这种情况.

此外,在部件号的情况下,规范化需要一个至少具有相同数量的记录而不是原始表中的额外列的附加表,这是否会在以后反规范以提高查询速度？

任何有关外部资源(包括其他论坛,教程,书籍)的提示,技巧或提示都将不胜感激.

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

戴夫

Answer 1

首先,不:多对多关系不是糟糕设计的指标.

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

但是连接表只是整数对,当你索引它们时,它们可以非常快.

编辑添加:

你评论说:

我认为索引是由DBMS完成的

由您来告诉DBMS要索引的内容.之后,保持索引最新是自动完成的.

有些DBMS拥有可以监控系统运行情况的工具,并建议您使用哪些索引.

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