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

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 и ввести таблицу общего режима, которая отображает режимы в идентификаторе общего режима

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

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

Answer 2

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

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

Красиво и просто на мой взгляд. Вы не получаете избыточных нулевых значений; если продукт имеет этот режим, то есть строка, если нет, то нет строки. Также означает, что не требуется никаких изменений схемы, если есть новое состояние. Если вы хотите, вы можете вместо этого связать 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)
)

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

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

Answer 3

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

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

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