数据库设计答案

【问题标题】：Database Design数据库设计
【发布时间】：2011-01-12 12:04:22
【问题描述】：

这是一个通用的数据库问题，与任何特定的数据库或编程语言无关。

我以前做过一些数据库工作，但通常都是可行的。这次我要为未来做打算。

我有一个存储备件列表的表。名称、部件号、位置等。我还需要存储它们也适用的设备。

一种方法是在我的备件表中为每个设备创建一个列。这就是在当前数据库中完成的方式。一个问题是，如果将来我想添加一个新设备，我必须创建一个新列，但这会使编程更容易。

我的想法是创建一个单独的适用性表。它将存储部件 ID 和设备 ID，如果一个部件适用于多个设备，它将有不止一行。

Parts
-------
ID
Name
Description
Etc...

PartsApplicability
-------
ID
PartID
DeviceID

Devices
------
ID
Name

我的问题是这是否是一种有效的方法，它会比原来的方法更有优势吗？还有更好的方法吗？

感谢您的任何回答。

【问题讨论】：

【解决方案1】：

我同意 Rex M 的回答，这是一种标准方法。您可以在 PartsApplicability 表上做的一件事是删除 ID 列，并使 PartID/DeviceID 成为复合主键。这将确保您的部件不能多次与同一设备关联，反之亦然。

【讨论】：

如果我们谈论大量的部分以及任何类型的新数据和不断变化的数据的流失，这可能会导致页面文件变得严重碎片化。我建议将自动增量字段保留为 PK 并索引其他字段。
@Rex M：我不明白页面文件的注释。还有：改变数据？两个相关的属性是外键。
@just someone：将这两个 ID 设为 PK 意味着该表在磁盘上按该顺序物理排序。因此，如果我们插入 (Part1/Device1)、(Part1/Device2)、(Part2/Device3)，那么 (Part 1/Device3) 数据库将不得不将表分开并在条目 2 和 3 之间插入最后一个。对于许多记录，这变得非常有问题，因为它涉及到每次添加一条记录时都会打乱数百、数千或数百万条记录。相比之下，自动递增的 PK 允许将新记录添加到末尾。
@Rex，您认为索引存储为一个数组，在添加和删除记录时需要上下移动？他们更有可能使用高效的平衡多路树，这绝对不会涉及对数千条记录进行洗牌。
@Rex M：你说的是一些不太聪明的实现细节。确实，SQL 数据库通常提供一种根据索引对表进行物理组织的方法，但这是特定于实现的，包括 DDL 语法，并且当前问题尚未使用任何特定的 SQL RDBMS（或physical-database-design ）。此外，paxdiablo 所说的。

【解决方案2】：

您正在使用中间连接表来描述 RDBMS 中多对多关系的标准设置。如果这就是您的模型最终将如何工作的方式，那么绝对是要走的路。

【讨论】：

【解决方案3】：

使用单独的表来保存多对多关系是正确的方法。

连接表的一些好处是

您似乎正在寻找database normal forms 的路上。第三范式或 BNF 应该是一个很好的目标，尽管有时打破规则是个好主意。

【讨论】：

【解决方案4】：

您的第二个设计是一个非常好的设计，在描述事物之间的关系方面，与我（在工作和我自己的项目中）多次所做的类似。查找表和它们的等价物通常比试图将所有内容都放在一个表中要简单得多。

也同意简化编程。最终，您会发现学习更多会使编程比尝试将事物推入您已经知道的事物中容易得多，即使它们确实不适合。知道如何正确连接表等将使您的数据库编程比不断修改列容易得多。

【讨论】：