Как организовать структуру таблиц в БД?

Question

[Руслан]

Здравствуйте!

Создаю интернет-магазин спортивной одежды и не могу правильно организовать структуру.
На данный момент есть таблица с каталогом товаров, где есть айдишник, имя товара, бренд, цена и описание. Эта информация выводится на экран пользователю при просмотре товара.

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

Я и не понимаю следующее:
1) Как привязать к товару размеры, то есть майка А имеет размеры L, XL и XXL, а у майки Б только XL.
(в таблице каталога товара создать столбец SIZE и вручную вбивать размеры нелогично и неудобно).
2) Как к привязанному размеру привязать ещё и количество, то есть опять же маек A в размере L имеется 7 штук, в размере XL 15 штук, а XXL осталась 1 штука.

Если можно, объясните на пальцах и поподробнее)

Answer 1

[Роман Сохарев]

Правильная организация:
goods
айди, артикул, ... , и прочие данные общие для всех товаров с данным артикулом (например бренд или айди бренда (если бренды хранятся в отдельной таблице); возможно, ссылка на основное изображение).
В общем, здесь описан непосредственно сам продукт, как таковой.

goods_variants
айди_варианта, айди_товара, опции товара, остаток.
Здесь все сочетания возможных опций для товара, с определенным айди. А так же возможная уникальная информация для конкретных параметров (возможно, информация о том, что товар акционный - допустим скидка 50% на супер большие размеры - здесь айди акции или что-то такое).
Например, если опции - это размер и цвет, то таблица в этом случае:
айди, размер, цвет, остаток, и еще что-то уникальное для данного варианта товара (ссылка на изображение, если цвет отличается, к примеру).
Само собой, сочетание полей айди+размер+цвет должно быть уникальным, во избежание дублей.

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

Comments

[Quber]

@greabock А можно поподробнее про последнее? Как организовать нечто сложное, скажем, каталог по типу яндекс маркета? Там у каждого товара куча всевозможных опций. При чём у каждой категории товаров там присутствуют свои опции.

[Роман Сохарев]

Тут нужно смотреть на конкретные цели и задачи. Я не возьмусь предполагать каким образом все это организовано в ЯМ. Но скорее всего подобные вещи делаются следующим образом:
1. Таблица options.
айди_опции, описание опции. (айди_опции уник.)
2.Таблица options_accepts
айди_опции, допустимое значение (айди_опции+допустимое значение уник.)
Тут можно поспорить о модели данных, ведь опция может содержать как допустимые конкретные значения, так и диапазон допустимых значений (но это снова тема для отдельной дискуссии).
3. Таблица product_variant_option_value
айди_варианта, айди_опции, значение. (айди_варианта+айди_опции уник.)
"Ну или как-то так"(с)...
Нечто подобное (с небольшими различиями) организовано во многих "крутых" (читать - популярных) CMS для интернет-магазинов.

[Роман Сохарев]

ЗЫ. Таким образом, таблица product_variant_option_value содержит "все-все-все" опции всех вариантов и их значения в общем, "плоском" массиве.

[Роман Сохарев]

З.З.Ы. Чуть не забыл:
4. Таблица product_options или category_options (Вообще, наличие данной таблицы - дело вкуса).
айди_продукта или айди_категории, айди_опции (айди_продукта/категории+айди_опции уник.)
В этой таблице, перечислены какие опции для каких товаров(или категорий товаров) допустимо использовать. Например, для штанов нужен размер одежды, а для фотоаппарата - разрешение матрицы.

[Роман Сохарев]

В целом, все это дико усложняет модель данных. И какие ни будь doctrine или propel сдуются с их фильтрами, при достаточном разнообразии ассортимента и количестве товаров. Так что, запросы к такой модели данных лучше писать руками.

[Quber]

@greabock я видел тему на хабре, где мусолили эту тему. В итоге всё свелось к тому, что надо использовать сериализованный массив как то и где то в таблице. Надо будет вспомнить и посмотреть еще раз эту тему.

Answer 2

[Rsa97]

Отдельная таблица (артикул, размер, остаток).

Answer 3

[Владлен Грачев]

Есть у вас таблица со списком товаров. Допустим, products. В ней столбцы с артикулом (id), названием, брендом и т.д.
Добавляете еще одну таблицу, например, sizes. В ней название размера (L, XL, т.д.), остаток, внешний ключ product_id, ссылающийся на id в таблице products.
А на странице товара получаете из бд не только данные из таблицы products по id, но и из таблицы sizes по аналогичному products_id.

Answer 4

[Quber]

Нужно вторую таблицу создать и назвать size. В ней четыре колонки:
id
Poduct_id
Size
Count

При занесении данных в таблицу указывается размер, ID товара и количество на складе.

Answer 5

[Рэшад]

1. Можно в БД хранить как массив, разделяемый при выводе, правда тогда 2 пункт не получиться.
2. Можно под каждое свойство сделать свою таблицу с id + кол-вом.
3. Можно посмотреть как реализованы такие вещи на крупных CMS ИМ
4. Можно вообще применить научный подход и попробовать абстрагироваться от смысловой нагрузки сделав функциональные зависимости и найти минимальное покрытие, правда тут может случиться, что на этапе создания функциональных зависимостей уже решиться 1 и 2 вопрос