什么是正确构建数据库的正确方法？

Question

我有以下属性

Auto Mechanic（id，name，mech_type，work_type，work_price）

例如：（1，John，车身修理，扰流板更换，100 $）

我把它分成这样的表

1. 汽车修理工（mech_id，mech_name）
2. Mechqual（mechqual_id，mech_id，mechtype_id）
3. mechtype（mechtype_id，mechtype_name）
4. 工作（work_id，car_id，mech_id，work_type，work_price） 因此mech-mechqual是M-M和mechqual-worktype 1-M。

但我认为这不好，因为你可以编写与机械机械类型无关的work_type。

例如：mechqaul - 制动技师work_type - 汽车涂装。 我应该改变什么？如何避免错误填写DB？

Answer 1

为了便于阅读，我更改了名称。我认为情况如下：

table(columns)                                    | sample content
--------------------------------------------------+------------------------------------------------------
worktype (worktype_id, name)`                     | 1/'body repair' , 2/'car painting'
workpart (workpart_id, worktype_id, name)         | 100/1/'spoiler replacement', 200/2/'partial painting'
mechanic (mechanic_id, name)                      | 123/'John'
ability  (mechanic_id, worktype_id)               | 123/1, 123/2
workdone (mechanic_id, workpart_id, price, car_id | 123/100/90$/4444

你担心，因为有了这个模型，DBMS无法阻止机械师无法工作的工作区。

这是因为这个数据模型完全基于单个技术ID，这个缺点不能保证层次结构的一致性。

如果您使用复合键：

table(columns)                                                 | sample content
---------------------------------------------------------------+--------------------------------------------------
worktype (worktype_no, name)`                                  | 1/'body repair' , 2/'car painting'
workpart (worktype_no, workpart_no, name)                      | 1/1/'spoiler replacement', 2/1/'partial painting'
mechanic (mechanic_no, name)                                   | 123/'John'
ability  (mechanic_no, worktype_no)                            | 123/1, 123/2
workdone (mechanic_no, worktype_no, workpart_no, price, car_no | 123/1/1/90$/4444

现在，workpart的主键是worktype_no + workpart_no。因此，没有workpart_no的{​​{1}}没有任何意义。只有组合会告诉您哪个工作部分。因此，workdone表包含worktype_no和worktype_no，以说明这项工作的内容。现在你可以对能力表有一个约束。问题解决了。

你还提到，这是关于客户的。客户有汽车和机械师。机械师应该只修理属于他们客户的汽车的问题。并且解决方案是相同的：机制将具有PK workpart_no + client_no并且仅machanic_no将不具有意义。汽车也一样。再一次，workdone表将包含构建适当的外键约束以防止出现不一致所需的所有信息。

结论：在单个技术ID上构建数据库没有错。该方法易于使用且广泛使用。但它确实有缺点，不能保证多层次的一致性（hierarchie）。这就是为什么我通常更喜欢在复合键上构建数据库，尽管（或者可能是因为）确定正确的密钥并构建数据库需要更长的时间。