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

Question

让我先说我知道我在标题中使用了“产品”这个词，尽管这是关于“服务”的，我觉得这个概念和我正在尝试实施的方法与产品选项的方法相同与我在标题中使用“服务选项”相比，每个人都可以更容易地联系起来。

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

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

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              |

但并非所有服务都具有必需或可选选项。但我正在尝试确定存储所有这些数据以生成报价的最佳方式。任何人都可以就这种设计是否有意义或以不同的方式看待我可能没有想到的事物提供一些帮助？

Answer 1

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

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