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

Добрый день.

Нужен совет от людей, разбирающихся в проектировании баз данных. Исходные условия таковы:
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, но такое решение уже кажется слишком громоздким для данной задачи.
  • Вопрос задан
  • 7542 просмотра
Решения вопроса 1
nochkin
@nochkin
Я бы сделал style_id int вместо style varchar в главной таблице и держал бы таблицу styles (int, varchar/unique). Таким образом не будет дубликатов, а главная таблица будет держать только id полей.
Когда появляется новый style, то он добавляется в таблицу styles.
Ответ написан
Пригласить эксперта
Ответы на вопрос 7
norguhtar
@norguhtar
Биллинги в телекоме мой конек
disc
@disc
веб-разработчик
Посмотрите в сторону документо-ориентированных СУБД, например MongoDB.
Ответ написан
Я бы сделал стандартным способом:
Product
— id
— name
— color_one_id
— color_two_id
— style_id
— fabric_id

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

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

По поводу клиентской части — используйте <select></select>.
Ответ написан
Комментировать
evnuh
@evnuh
Поиск Гугл помог мне, впусти и ты его в свой дом
Боже мой. Посмотрев на советы, ужаснулся. Вы же запугаете сейчас автора вопроса. Чтобы ответить на этот банальнейший вопрос, ему достаточно прочитать не то, что книжку, а какую-нибудь статью по проектированию БД, это ж основа основ.
Ответ написан
@eresik
Судя по вопросу:
1. у вас там явно не тысячи наименований товара.
2. вы не программист

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы