Как лучше хранить информацию о заказе в базе данных?

Question

[Bel0g0r]

Как лучше хранить и обрабатывать заказ из интернет магазина? На данный момент есть два варианта:
1. Хранить номер заказа и каждый товар из заказа отдельной строкой, с ключом номером заказа.
2. Хранить все в одной строке, в ячеках с разделителями | ( пример: ячейка id товара - 134|543|243) и обрабатывать через explode();

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

Comments

[Модератор]

Bel0g0r дорогой пользователь, настоятельно рекомендуем еще раз обратить самое пристальное внимание на п. 3.1 регламента работы сервиса (и, в особенности, на его последний абзац).
В противном случае, ваши вопросы будут удаляться по причине тег-спама.

[Bel0g0r]

То есть по вашему тег phpmyadmin не подходи что ли? А где по вашему тип данных выбирается? Я писал теги которые по моему мнению напрямую относятся к вопросу.

Answer 1

[Игорь Яцевич]

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

Например, я бы задался след вопросами:
1. После того как я положил в базу товары что мне с ними надо будет делать?
Если просто показать названия заказанных товаров в странице админки, то достаточно будет денормализованной формы хранения.
Если же на основании данных, которые содержит в себе заказ хочется строить динамическую аналитику - например, в админке товаров простым запросом показывать сколько раз этот товар покупали, либо что то в этом духе - то будет удобнее нормальная форма. Ну либо обновлять какой то счетчик заказа у товара, тогда нормальная форма не нужна.

2. Сколько строк в заказе будет в среднем? если очень много позиций в заказе - например по 1000 и заказов много - то очень скоро объем данных в таблице с элементами заказа будет большой, и выборка по нему будет деградировать. Если данных очень много - то лучше будет денормализованная форма. Если данных мало - то наоборот.

и т.д.

И я бы лучше использовал в базе для хранения списка ID не строку с разделителями, а JSON - поле такого типа есть в Postgres, с Mysql давно не работал - но кажется тоже есть. Либо тупо в текстовое сохранять json. Если такой тип данных поддерживает база, на него можно даже строить индексы. Либо если есть, то можно рассмотреть тип данных Array если поддерживает БД.

p.s. Реляционная база данных не обязывает хранить все только в нормальной форме - ее мощь как раз в том, что можно хранить и в нормализованной форме и в денормализованной.

Answer 2

[Stalker_RED]

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

Если вам на такие умные штуки пофиг - то как угодно. На масштабах в десятки-сотни тысяч заказов вы скорее всего разницы не заметите (ну если базу не ронять и не переделывать сильно пока работает).
А если разрастется, то одними заказами дело не ограничится, переделывать все равно придется.