Структура базы данных для элементов с различными атрибутами

Question

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

Каждый товар (предмет одежды) будет подвергнут фотосъемке несколькими способами, назовем их «режимами». Например, рубашка будет сфотографирована застегнутой или расстегнутой и/или заправленной/не заправленной. Пара брюк будет иметь другой набор возможных атрибутов. Я хочу хранить информацию о том, как эти предметы сфотографированы, поэтому я могу позже использовать эту информацию для отображения предмета одежды определенным образом.

Так один метод будет просто хранить все возможные атрибуты в одной таблице, что-то вроде:

PRODUCTID (FK, PK) modeId (PK) isLoose isTuckedIn Размер HasSmthUnderneath

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

Затем, учитывая конкретный productId и modeId, я предполагаю, что могу отфильтровать значения NULL для атрибутов, которые не применяются, и использовать только соответствующие.

Однако я не уверен, что это идеальный способ хранения таких значений, поскольку у меня было бы много значений NULL, например, в паре брюк, которые только сфотографировались в одном направлении. Я слышал о модели EAV, это уместно?

Возможно, стоит отметить, что количество атрибутов будет определяться мной, а не пользователем, и не должно сильно меняться; и моя конечная цель - извлечь атрибуты определенного режима, чтобы я мог использовать эти данные в своем приложении.

Извините, если что-то неясно!

Answer 1

Я был бы соблазн иметь следующий нормированный дизайн схемы

Mode Table 

id | mode_style 
--------------- 
1 | buttoned 
2 | unbuttoned 
3 | tucked in 
4 | untucked 

Clothes Table 

id | name  | description 
---------------------------- 
1 | shirt  | mans shirt... 
2 | dress  | short sleeve 

Clothes_mm_Mode Table (Junction/Map table) 

mode_id | clothes_id 
-------------------- 
1  | 1 
1  | 2 
3  | 3 

Затем вы можете легко запросить ту одежду, которые имеют расстегнутом дисплей

SELECT 
    c.id, 
    c.name, 
    c.description 
FROM 
    Clothes c 
INNER JOIN 
    Clothes_Mode cm 
    ON c.id = cm.clothes_id 
WHERE 
    cm.mode_id = 2 

Если определенные виды одежды всегда отображаются в таким же образом, т.е. все рубашки всегда имеют застегнутый застежкой и расстегнутый дисплей, вы можете вынуть таблицу Clothes_mm_Mode и ввести таблицу общего режима, которая отображает режимы в общий режим id

Common_Modes Table 

id | name   | description 
-------------------------------------------------- 
1 | Men's Shirt | Common Modes for a Mens shirt 
2 | Women's Shirt | Common Modes for a Womens shirt 

Common_Modes_mm_Mode Table (Junction/Map table) 

common_mode_id | mode_id 
-------------------------------------------------- 
1    | 1 
1    | 2 
2    | 1 
2    | 2 

, а затем связать каждый элемент одежды с общим типом Режима

Clothing_Common_Modes Table 

clothing_id | common_mode_id 
---------------------------- 
1   | 1 

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

Answer 2

Я думаю, что ваш дизайн в порядке. Можно было бы применить database normalization к нему, которые могут дать вам следующие конструкции в качестве альтернативы:

1. имеют одну таблицу на одну собственность, каждый из которых (ID, propvalue) пар. Добавляйте строки в эти таблицы только для элементов, в которых свойство действительно применяется.
2. имеют общие таблицы (id, propname, propvalue), возможно, одну такую ​​таблицу для типа данных свойства (логическое число, число, строка).

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

Answer 3

Я лично считаю, что простые старые пары ключ/значение для этого типа недооценены, поэтому, если вы счастливы контролировать его больше в самой заявке вы также можете сделать что-то вроде этого:

create table ProductStates 
(
    ProductId int PK 
    ModeState nvarchar(200) PK 
) 

Nice и простой в моем сознании. Вы не получаете избыточных нулевых значений; если у продукта есть этот режим, тогда есть строка, если нет строки. Также означает, что никаких изменений схемы не требуется, если есть новое состояние. Если бы вы захотели, вы могли бы заставить ModeState вместо этого ссылаться на таблицу поиска ModeStates, если вы считаете, что проблема целостности будет проблемой.

create table ProductStates 
(
    ProductId int PK 
    ModeStateId int PK 
) 

create table ModeStates 
(
    ModeStateId int PK 
    ModeStateDescription nvarchar(500) 
    (...whatever else you might need here) 
) 

...хотя это, вероятно, избыточно.

Просто альтернатива, не уверена, что я сделаю это сам (зависит от краткости (-ов)). Правильно ли я получил спецификацию?