Хранение нескольких вариантов продукта в базе данных

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