我有一个“产品”数据库，用于存储产品详细信息。对于每个产品，它可以选择有0-10个备件，并通过动态表单接受它们的名称。
我不确定数据库模式应该是怎样的。从这条线，我得到了一些想法，这就是我想到的。
__________________________________
|products |
|********* |
|id, name, address |
|__________________________________|
__________________________________
|spareparts |
|********* |
|id, name |
|__________________________________|
__________________________________
|products_spareparts |
|********* |
|id, product_id, sparepartid |
|__________________________________|所以我的想法是在“spareparts”表中有10行，因为一个产品的备件不会超过10个。每一行都有一个id和name字段，其中存储从表单接受的名称。
创建产品时，如果有备件，则每个备件的名称将添加到“备件”表中，产品id和备件id将分别保存产品和备件的id。
备件是按产品创建的。它的名称是从表格中接受的，两个产品可能有或可能没有相同的备件。
这样行吗？有没有更好的方法来实施？
2条答案
按热度按时间dbf7pr2w1#
关系数据库可以很容易地限制0/1关系的关系。它们不容易限制任意数字的数量。
基本上，合理的解决方案需要使用触发器。触发器将计算给定产品的当前备件数量。如果它超过某个阈值（在您的情况下是10），那么您将在另一个insert上得到一个错误。
我会用两种方法中的一种来计算备件数量。如果我只是坚持传统的数据库结构，我会把一些备件放进去
products并使用check对值的约束。触发器将用于使值保持最新。更有可能的是，我会将所有dml操作 Package 到存储过程中，并在那里进行检查。这要求dml操作都通过存储过程来处理。
“不合理”的方法是将ID列表作为单独的列--
spareparts1,spareparts2，等等。这允许您维护外键关系并限制数字。然而，这使得后续的备件查询更加复杂。7eumitmz2#
参考david的答案，我最终使用了上面的模式。productid只是关联产品的外键。对于每个备件，都会在spareparts数据库中添加一个新行，其中包含相应的产品id。在这种情况下，不需要第三个表。