Как корректно составить ERD?

Question

[Андрей Билык]

Добрый день. Подскажите как лучше составить структуру продукта и его декораторов.

Под декораторами тут понимается, например:
1) Упаковочная бумага (FK на соотв. справочник)
2) Упаковочная лента (просто как услуга, есть или нет)
3) Гравировка продукта - нанесение текста (нескольких текстов) на продукт
и другие.

С одной стороны, все декораторы вынесены в справочник, имеют свой ключ и свою стоимость:
Decorators

id	name	price
1	Бумага	10
2	Лента	5
3	Текст	2

Напрашивается сводная табличка между продуктом и несколькими его декораторами
ProductDecorators
id product_id decorator_id decorator_price

И эта структура прекрасно бы работала, если бы не разные типы декораторов.
Так, для бумаги надо указывать внешний ключ на справочник, который для всех остальных декораторов необязательный.
Для текстов нужно дополнительно указывать параметры (сам текст, положение на продукте) + текстов может быть несколько для одного продукта..

Как лучше поступить в таком случае?
Можно, например, вынести декораторы вроде "Упаковочная бумага", "Текст" в отдельные сущности с FK на продукт, а однотипные и "линейные" декораторы оставить в ProductDecorators.

Однако в этом случае получаем зависимость - часть декораторов разнесена в одни таблички (и должна обрабатываться на уровне кода), часть подчиняется общей логике ... что уже совсем нехорошо.

Answer 1

[robofox]

Создать таблицы с параметрами декораторов. Например:

decor_text_params:
id   product_id   text_value   text_position   text_param1   text_param2

decor_paper_params:
id product_id paper_type paper_size paper_param1 paper_param2

В них же будет привязка к продукту. Да, добавится обработка на уровне кода.

Если хочется обойтись без привязки к коду, можно завести таблицы параметров декораторов.

decor_params_definition:
id   decor_id   param_name  param_type  ...

Заполнение:
1   1   "Цвет бумаги"  "color"
2   1   "Размер бумаги"   "int"

В другой таблице хранить значения параметров в виде строк, на уровне кода преобразовывать их к нужным типам.
Такая структура полезна, если параметры будут постоянно добавляться или изменяться, и они нужны только для отображения. Если с параметрами придется работать в коде, лучше жестко их привязать.