Mysql 在数据库中存储多个产品选项

让我先说一句，我知道我在标题中使用了“产品”一词，尽管这是关于“服务”的，但我觉得我试图实现的概念和方法与产品选项的方法相同，并且每个人都比我在标题中使用“服务选项”更容易联系起来

我正在为我的新汽车维修业务网站建立一个数据库。我正在努力为我提供的各种服务存储选项。例如：

一位客户上网要求更换前制动卡钳。在这种情况下，维修为“制动卡钳更换”，维修选项为“前”。我将这些存储在表中：

Services

| ID | Service Name              |
----------------------------------
| 1  | Brake Caliper Replacement |
| 2  | Oil Change                |

我有第二个表，其中存储了每个服务的所有潜在选项，并指出该选项是必需的还是可选的。在报价过程中，我在网站上使用这些字段，以确保它们选择所需的选项之一

服务选项

| ID | Service_Id | Service Option | Required | Optional |
----------------------------------------------------------
| 1  | 1          | Front          | 1        | 0        |
| 2  | 1          | Rear           | 1        | 0        |
| 3  | 1          | Pad Replacement| 0        | 1        |

现在，当他们填写报价的其余部分，并选择他们想要的服务选项时，我正在为如何存储关系而挣扎

以下是我目前的安装方式：

Quote

| ID | Customer Id | Vehicle Id |
---------------------------------
| 1  | 1           | 2          |

Quote Service

| Quote Id | Service Id | Service Option Id |
---------------------------------------------
| 1        | 1          | 1                 |
| 1        | 1          | 3                 |
| 1        | 2          | null              |

---

但并非所有服务都有必需或可选选项。但我正试图确定存储所有这些数据以生成报价的最佳方式。有没有人能提供一些帮助，看看这种设计是否合理，或者是否有一种不同的方式来看待我可能没有想到的事情？

我认为最灵活的设计是一个自连接的服务产品表，有些是必需的，有些不是，这取决于每个产品在其父产品下的悬挂方式。它总是为层次结构中的子类别级别提供最大的灵活性

create table service
(   -- services (and sub-services) self-join hierarchy
    -- pricing naturally has no business in this table
    -- it must be kept high-level and generic enough to handle all autos
    -- from Hyundai to BMW
    serviceId int auto_increment primary key,
    description varchar(255) not null, -- the service name
    required int not null, -- 1 means required, 0 means optional
    parentId int not null -- 0 means no parent, otherwise serviceId of parent
);

甚至可以在表服务中使用外键约束，但对于版本2也是如此

---

Quote

将有两列：

quoteId

和

serviceId

不保存空的最后一行。事实上，他们只想做正面的事情。重新整理您的第一张桌子显示您可以为所有需要的服务提供一个服务选项（例如基本）。也许这样的服务将是“提升罩”，我想最灵活的设计是一个自连接的服务产品表，有些是必需的，有些不是，这取决于每个产品在其父产品下的悬挂方式。该表将有一个int id

parentId

我添加了最后一行，以显示我如何处理未选择任何选项的服务。我喜欢这个想法，我想我从来没有想过需要的选项，如前部和后部，作为实际的服务，我想它们在技术上是。因此，我将有3个制动卡钳服务，“制动卡钳更换”，“前制动卡钳的更换”、“后制动卡钳的更换”“.这就是你的建议吗？是的。由于你的交易的细微差别，它们是不同的。当所有车型的id不再不同时，将它们合并为一行。诀窍是在开始时尽量少保留行，这样以后就不必将它们合并为一个id，而旧id会浮动在那里，没有父id可供参考（也称为孤儿）。外键约束为您解决了这个问题，但留下了一堆不再有效的服务，因此需要考虑相当多的问题。我正在考虑一个字段，该字段指示当前是否提供了该服务。我真的很喜欢它，它解决了我现在面临的一系列问题。它还删除了当前设计下的一些冗余数据。