Как хранить несколько элементов справочника в поле?

Question

[ggagnidze]

Доброго дня.

Предположим, что компания занимается доставкой товаров.
У нее есть справочник (таблица MySQL) товаров:

1 Апельсиновый сок
2 Ананасовый сок
3 Березовый сок

Клиент оказался гурманом и заказал Ананасовый и Березовый сок.

Вопрос: как правильно отразить этот заказ в таблице заказов с точки зрения MySQL?
Нужно ли указывать ID товаров через запятую в одном поле или следует сделать как-то иначе?

Спасибо.

Answer 1

[Дмитрий Сергеев]

Я бы сделал так. Две таблицы:
1. Таблица user_order — хранит userId и orderId (генерируется когда пользователь оформил заказ, orderId есть primary autoincrement id для таблицы orders)
2. Таблица order_item — хранит orderId и itemId

Comments

[deleted-mifki]

Зачем user_order?

Answer 2

[JustLuckyGuy]

двоичным числом. или как это правильно называется.
01 — апельсин
10 — ананас
11 — береза

т.е. если клиент заказал все 3 сока, то будет 100 (все числа в двоичной системе). соответственно переводишь в десятичную и в путь.

Comments

[JustLuckyGuy]

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

[Doktor_Gradus]

Не каждый новый. 3 битами шифруется 8 товаров. Забив сразу 16 бит (всего 2 байта), можно получить 65к товаров — этого любой некрупной компании хватит. Ну а не хватит, увеличить ещё на байт, будет уже 16 миллионов наименований.

[Doktor_Gradus]

Чёрт, не совсем так. Нужно же ещё суммы разворачивать.

[ggagnidze]

Answer 3

[adminimus]

можно использовать три таблицы: номенклатура товаров, заказы, позиции в заказах. В третью таблицу пишите две строки (Ананасовый и Березовый сок) с привязкой к строке таблицы «Заказы» по id заказа например.
Можно конечно складывать заказы в одну таблицу и писать позиции в одно больше поле. Формат берете какой удобно (plain text, xml, json, сериализованные объекты...), парсить его вам все равно придется отдельно кодом. Минус этого решения в том, что поддерживать ссылочную целостность базы будет очень геморройно. Ну и очевидные накладные расходы на хранение и обработку

Answer 4

[ggagnidze]

Мне прямо не верится что нет готовых решений. Это же задача любого интернет-магазина, коих великое множество. Lолжна же быть Best Practice.

Comments

[savant]

обычно используют many to many связь между заказом и товаром как выше написали про order и order_item.

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

А вообще — в БД можно держать данные в нормализованном виде, а в кешах держать развёрнутую таблицу, для быстрого поиска, но тут опять накладные расходы на генерацию этой таблицы при изменениях и поддержание актуальности данных в кешах и БД.

Ну или нафиг отказаться от sql и посмотреть в сторону nosql БД.

[Hint]

JetMaster написал вам о стандартном решении. Лучше ничего не придумаете.

[JustLuckyGuy]

Так вы интернет магазин делаете? А зачем нам мозги парите про компанию доставляющую товары?

Answer 5

[Mikhail Osher]

NoSQL Вам в помощь.
Если все-таки MySQL — согласен с JetMaster

Answer 6

[dali]

Без разницы, MySQL или любая другая реляционная база данных. Нормализуется хотя бы до 3 нормальной формы. Все, как расписал JetMaster и savant.

Answer 7

[Sild]

Вроде бы хранить 2 значения в одном поле противоречит то ли нормальным формам, то ли реляционным БД в целом

Answer 8

[chuck]

Если есть возможность перейти на Postgres, то там есть тип данных — массив.