Как правильно работать с разными типами продуктов

[dron4ik]

Всем привет!
Есть задача "Заказ продуктов". Продукты могут быть 3 разных типов, каждый со своим набором свойств, как лучше спроектировать БД?

Предполагаю сделать примерно так:

CREATE TABLE IF NOT EXISTS `order_item` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `order_id` int(11) DEFAULT NULL,
  `order_type1_id` int(11) DEFAULT NULL,
  `order_type2_id` int(11) DEFAULT NULL,
  `order_type3_id` int(11) DEFAULT NULL,
  `user_id` int(11) DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `order_id` (`order_id`),
  KEY `order_type1_id` (`order_type1_id`),
  KEY `order_type2_id` (`order_type2_id`),
  KEY `order_type3_id` (`order_type3_id`),
  KEY `user_id` (`user_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

но выглядит топорно, может есть более элегантные варианты?

 

[accido]

order_type ENUM(1,2,3)
order_parameters INT(11)
- не ?

 

[peon]

погугли нормализацию бд

 

[badmovie]

Для решения задачи, нужно больше вводных данных. Покажи структуру таблиц items и таблицу, которую ты используешь для хранения уникальных свойств.
Надо посмотреть на всю картину в целом и используя "нормальные формы" спроектировать корректную структуру БД.

Т.к. даже order_type ENUM(1,2,3) , order_parameters INT(11) не самый изящный подход.

Всем привет!
Есть задача "Заказ продуктов". Продукты могут быть 3 разных типов, каждый со своим набором свойств, как лучше спроектировать БД?

Предполагаю сделать примерно так:

CREATE TABLE IF NOT EXISTS `order_item` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `order_id` int(11) DEFAULT NULL,
  `order_type1_id` int(11) DEFAULT NULL,
  `order_type2_id` int(11) DEFAULT NULL,
  `order_type3_id` int(11) DEFAULT NULL,
  `user_id` int(11) DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `order_id` (`order_id`),
  KEY `order_type1_id` (`order_type1_id`),
  KEY `order_type2_id` (`order_type2_id`),
  KEY `order_type3_id` (`order_type3_id`),
  KEY `user_id` (`user_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

но выглядит топорно, может есть более элегантные варианты?

 

[dron4ik]

Таблицы параметров в общем произвольные, но в моём случае это:
1, int, int, int, string, datetime, datetime
2, int, int, string, datetime, datetime
3, int, int, int(files_set_id), string, datetime, datetime

Тоесть цифры и строки, плюс у третьего - список файлов загруженных пользователем.

Поэтому enum не подходит.

По Типам проходит ось изменений, тоесть необходимо выработать такое решение, которое позволит более оперативно добавлять типы, сейчас это не очень удобно.

 

[Linker]

dron4ik, вначале речь шла про "три типа", оказалось:

По Типам проходит ось изменений, тоесть необходимо выработать такое решение, которое позволит более оперативно добавлять типы, сейчас это не очень удобно.

классическое решение: отдельная таблица типов.

 

[badmovie]

Я бы сделал так, но все сильно зависит от задачи. Битрикс например хранит все свойства в одной таблице(это настраиваемое поведение, но достаточно смешное - когда кол-во свойств товара превышает количество допустимых столбцов у таблицы).
А вообще почитай что-нибудь на тему проектирования реляционных баз данных, например "Основные концепции баз данных" Ф.Д. Ролланда. Попробуй поставить MySQL Workbench и создать для своей БД EER-диаграмму.

 

[dron4ik]

Блин, я не верно локализовал проблему.

Спасибо за предложенный вариант. Накатал в воркбенче схему того как примерно мне нужно

тут вопрос как привязать таблицу Catalog.
По сути у меня типы такие :
Тип1 - должен иметь одну привязку к Каталогу
Тип2 - 3 привязки(свойства) из Каталога (набор товаров)
Тип3 - Вообще не использует привязок к Каталогу, но использует файлы

Сейчас моя часть ERR выглядит так:

Конечно хочется иметь более универсальный вариант, потому и писал что типы будут меняться, но в этом проекте эти 3-х типа покрывают всё что необходимо.

Видимо так и придётся оставить.

 

[Linker]

dron4ik, у badmovie вариант более универсальный, просто "урезанный" для примера.
А у вас смешались в кучу "типы" и "свойства" в одной таблице.
Теоретически, можно как угодно, можно и так, как в примере, но лучше было бы "свойства" вывести в отдельные таблицы, причём там могла бы быть очень обширная структура (свойства по группам, типам, или и то и другое при необходимости).
В результате у вас будет возможность сформировать более универсально и гибко "товарную позицию", которая будет храниться в отдельной таблице и будет связана с другими таблицами:
- товары (типа вашей "catalog_articul")
- типы товаров (отдельная таблица в которой будут собраны все ваши "order_type*")
- свойства товаров (туда как раз перейдут такие поля как "length", "angle" и т.д.)
...
- тут ещё может быть много всего, что нужно...
...
а уже в таблице "заказов" будет связь с записями "товарных позиций", а также с записями из таблицы цен (я пока не вижу у вас, но теоретически должно быть что-то в виде записей в отдельной таблице, где к каждой "товарной позиции" могут быть привязаны записи вида "id_товарной_позиции - дата - цена")

т.е. у вас в результате будет много "таблиц-справочников" так называемых, в них будут "товары", "типы", "группы", "свойства" и т.д. а ещё будут таблицы, в которых будут соединятся "товары" с "группами", "типами", "свойствами", а они уже в свою очередь, будут соединяться с "заказами", "корзинами", "счетами" и т.д.

Всё это разрастётся до очень большого количества таблиц и связей, которое, в конце концов, можно будет (хотя и не факт) немного оптимизировать, слегка упростив общую схему.