[БД] Как лучше хранить атрибуты товара, если их количество известно и не будет меняться?

Question

[Bright]

Добрый день.

Нужен совет от людей, разбирающихся в проектировании баз данных. Исходные условия таковы:
1) есть один тип товара (и других не будет)
2) у товара фиксированное и известное количество свойств (максимум 2 разных цвета, форма, материал)

В дальнейшем по данным свойствам необходимо выполнять поиск товаров.

Самое очевидное решение — добавить столько полей в таблицу product, сколько у нас свойств:

PRODUCT
- id
- name
- color_one
- color_two
- style
- fabric

Но дальше возникает вопрос — как поступать с представлением свойств? Делать поля VARCHAR и позволять пользователю самостоятельно вписывать значения не слишком правильно — будут опечатки, неизбежно появятся дубли значений. К тому же, количество возможных значений для каждого из свойств не так уже велико (т.е. проще заранее составить список возможных значений для каждого свойства и потом уже просто выбирать значение из списка).

Создавать отдельные таблицы для каждого свойства (COLOR, FABRIC, STYLE) тоже кажется лишним. Поэтому пока пришёл к такому решению:

PROPERTY
- id
- property_name
- property_value

И поля в таблице PRODUCT просто содержат ссылки на записи из таблицы PROPERTY. Нормальное ли это решение? Возможно есть способы сделать это лучше?

PS: да, понимаю, что по сути между PRODUCT и PROPERTY получается связь MANY-TO-MANY и можно вообще выкинуть поля, представляющие свойства, из таблицы PRODUCT, а связь реализовать через ассоциативную таблицу PRODUCT_PROPERTY, но такое решение уже кажется слишком громоздким для данной задачи.

Comments

[Bright]

Собственно, нашёл очень похожий вопрос здесь: dba.stackexchange.com/questions/24636/product-attribute-list-design-pattern (с разницей лишь в количестве типов продуктов). В первом ответе описывается такое же решение, как я упомянул в PS.

Кстати, ещё хотелось бы узнать какое из всех этих возможных решений адекватней в плане производительности?

Answer 1

[nochkin]

Я бы сделал style_id int вместо style varchar в главной таблице и держал бы таблицу styles (int, varchar/unique). Таким образом не будет дубликатов, а главная таблица будет держать только id полей.
Когда появляется новый style, то он добавляется в таблицу styles.

Comments

[Bright]

Да, именно к такому решению я и пришёл. Вопрос теперь в том делать ли отдельные таблицы под каждое из свойств или будет их вполне нормально объединить в одну (в этом случае в product получится несколько внешних ключей к одной и той же таблице property)?

[nochkin]

Я бы делал разные если заранее известно количество свойств и оно точно не будет изменяться. Маленькие таблицы будут кешироваться.
Так же нету риска когда по какой-то причине (баг в коде или ещё что-то) style_id, например, указывает на id цвета.

Answer 2

[Анатолий Шипицын]

Ну классика же жанра Entity–attribute–value model

Comments

[Bright]

EAV в данном случае излишне, разве нет?

[Анатолий Шипицын]

Почему? Как раз подходит.

[Bright]

Хм. Ну меня скорее смущает сложность запросов при отображении/поиске продуктов…

[EugeneOZ]

классика тормозов и многоэтажных джойнов

[Анатолий Шипицын]

Предложите лучше.

[Bright]

Насколько я понимаю, получается так:

EAV, отображение списка продуктов: 2 джойна
Отдельные таблички под свойства / одна таблица, отображение списка продуктов: количество джойнов = количеству свойств

EAV, поиск продуктов по атрибутам: ??
Отдельные таблички под свойства / одна таблица, поиск продуктов по атрибутам: простенький запрос типа SELECT * FROM products WHERE color_id IN (%список_id_цветов%) AND fabric IN (%список_id_тканей%)

[Анатолий Шипицын]

Отдельные таблички под свойства / одна таблица, отображение списка продуктов: количество джойнов = количеству свойств

Эм вы точно все верно читали? Там три таблицы. Товар, атрибут и его значение. Таблица атрибутов и таблица значений одна. Далее просто есть связка где указан товар, какой атрибут и тип значения. Так что если вы не будете разворачивать товар как плоскую таблицу вида

название товара, значение свойства а, значение свойства б

то будет два join

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

[Анатолий Шипицын]

Так посоветуйте паттерн в чем проблема?

PS за одно расскажите в чем он антипаттерн

[Bright]

Да, я это не про EAV написал, а про случай если всё-таки под каждое свойство заводить отдельные таблицы.

Поиск будет через Zend Lucene, т.к. других вариантов вроде бы особо и нет. Сайт будет размещаться на обычном shared хостинге, Sphinx туда точно не поставишь. Но поиск — это одно, а фильтры товаров — всё-таки другое.

Answer 3

[Александр]

Посмотрите в сторону документо-ориентированных СУБД, например MongoDB.

Comments

[max_rip]

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

[EugeneOZ]

за тем, max_rip. плюсую ответ.

Answer 4

[Макс Кузнецов]

Я бы сделал стандартным способом:
Product
— id
— name
— color_one_id
— color_two_id
— style_id
— fabric_id

И соответствующие таблицы: COLOR, STYLE, FABRIC. Если у вас не супер-посещаемый проект, то больше ничего и придумывать не нужно.

Оптимизация 1. Если, например, стиль четко определен, то его можно хранить как ENUM.
Оптимизация 2. Если вас напрягают допзапросы, то храните списки цветов, стилей и материалов в виде серверных конфигов (в виде простых массивов).

По поводу клиентской части — используйте <select></select>.

Answer 5

[evnuh]

Боже мой. Посмотрев на советы, ужаснулся. Вы же запугаете сейчас автора вопроса. Чтобы ответить на этот банальнейший вопрос, ему достаточно прочитать не то, что книжку, а какую-нибудь статью по проектированию БД, это ж основа основ.

Comments

[Bright]

Может посоветуете, какую конкретно статью стоит прочитать?

Я, в принципе, и так с этим вопросом не сразу полез на хабр, а сначала прочитал пару схожих вопросов на StackOverflow. Но пока окончательного ответа как стоит сделать (и главное — почему) для себя не нашёл.

Answer 6

[eresik]

Судя по вопросу:
1. у вас там явно не тысячи наименований товара.
2. вы не программист

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

Answer 7

[asmerdev]

SQL ENUM && HTML SELECT?

Comments

[Bright]

HTML SELECT — да, именно так и хочется реализовать эти элементы в форме.

SQL ENUM… Не для всех свойств заранее известны все возможные значения. Например, «стиль» — известно заранее, там четыре возможных варианта. А вот цвет — чёрт его знает. Пока наберётся меньше десятка разных цветов, но в будущем возможно появятся и другие. Аналогично и с тканями.

[tgz]

Сдлеать свой класс типа ENUM в web движке который будет маппить в обычный SQL TEXT. Ну и в интерфейсе изобразить возможность расширения этого списка.

Answer 8

[Arks]

Захотели изменить список — написали ALTER TABLE. А хранить все в ENUM — простота очевидна, а стили те же хоть заранее и неизвестны, не каждые же 3 минуты меняются. И никаких JOIN'ов не надо писать. JOIN'ы актуальны не когда в справочниках < 100 записей, а когда это реально СПРАВОЧНИК. В остальном ENUM и ALTER TABLE вполне себе серебряная пуля.