MySQL « Хранение свойств товаров в БД

Предполагается каталог товаров, которые имеют свои характеристики - вес, высота, уровень радиации и прочее-прочее. Пользователем товары будут добавляться в таблицу сравнения (важный момент!). Для хранения товаров используется первая таблица, для видов характеристик - вторая, для значений характеристик - третья. Упрощенно:
  1. products (id, title)
  2. products_properties (id, title, type (тип характеристики - число, текст, список предопределенных и т.д.))
  3. products_properties_values (id, product_id, property_id, value???)

С первыми двумя таблицами все понятно, а с третьей загвоздка: так как тип характеристики может быть и простым числом, и текстом, и еще неизвестно чем — какой тип поля установить? Самый простой вариант - сделать TEXT, куда можно записать что угодно. Но тут и возникает упомянутый нюанс - отбор по значению характеристики. В этот случае производительность упадет ниже плинтуса, так как ставить индекс на поле этого типа глупо.
0
mysql бд Нормализация

1 ответов

Посмотрите здесь: http://www.askdev.ru/net-platform/2596/Как-выгрузить-коллекцию-объектов-в-БД/.
Если будут какие-то вопросы дальше - you're welcome в комментарии. ;)

UPDATE:
Вот ещё: http://www.askdev.ru/php/2687/Хранение-различных-свойств-товара/.

UPDATE:
Задача - сравнивать характеристики различных товаров.
Товары храним в категориях.
Возможность сравнить товары различных категорий, определяем на уровне связей между категориями.
Типы свойств товаров храним отдельной таблицей, сравнивать можно только одинаковые типы свойств.
Наличие определённых свойств у той или иной категории определяем привязками.
Собственно, вперёд:
TABLE Categories (Id, Name)
TABLE ComparableCategories (Id, Category1Id, Category2Id)
TABLE PropertyTypes (Id, Type, Name)
TABLE CategoryProperties (Id, CategoryId, PropertyTypeId, Name)
TABLE Products (Id, Name, CategoryId)
TABLE ProductIntegerProperties (Id, ProductId, CategoryPropertyId, Value)
...
Пример
Categories:
1 - Телевизоры
2 - Мониторы
ComparableCategories:
1 - 1 - 2
PropertyTypes:
1 - Integer - Размер (дюймы)
CategoryProperties:
1 - 1 - 1 - Диагональ
2 - 2 - 1 - Диагональ
Products:
1 - JVC - 1
2 - Samsung SyncMaster - 2
ProductIntegerProperties:
1 - 1 - 1 - 42
2 - 2 - 2 - 19

Немного сумбурно, но думаю разберётесь.


0

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

0

В реляционных СУБД задача нормально не реализуется.
Либо для разных типов несколько таблиц, либо все значения в поле типа VARCHAR.
Не забываем также, что бывают типы, например, «диапазон» (температура нагрева от и до) или «диапазон с дискретными значениями» (вентилятор с переключателем скоростей вращения). Единицы измерения пользователи также захотят хранить в БД и привязывать к значению атрибута. Гуглите по словам «EAV» и «модель Тенцера», но вряд-ли найдете какое-нибудь откровение.
Хранение значений в разных таблицах существенно увеличивает нагрузку на сервер, как на БД, так и на сервер приложения. Хранение все в поле типа VARCHAR существенно сужает возможности построения фильтров.
Как правило, если есть возможность, стараются для товаров сделать отдельные модули или просто изначально делают скрипт под какой-то конкретную группу или группы товаров. Или некоторое API для получения атрибутов и их значений и модуль по-умолчанию, работающий с таким API — получается возможность написать расширение для конкретной группы или оставить жадного заказчика колупаться с тем бедным функционалом, который есть «в базе» :).

0