Проблема дизайна базы данных - несколько баллов в разных категориях

Question

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

Например, одна категория может быть «поводом». Возможны следующие случаи:

Одежда в офисе Носить на свадьбу Носить на свидание ... Носить на похороны

Каждому продукту нужно присвоить 10 баллов для каждого из них. Таким образом, один продукт может иметь:

Отделение: 5 Свадьба: 7 Дата: 10 Похороны: 0

Что означало бы, что предмет - что-то веселое, не слишком преуменьшенное, возможно, не слишком формальное.

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

Возможно хранить таким образом, кроме как в другой таблице с объединением? Просто ищу достаточно гибкое и элегантное решение.

Если я не был ясен, пожалуйста, дайте мне знать.

P.S Я использую MySQL, если это имеет значение ...

РЕДАКТИРОВАТЬ: Я не думаю, что иметь таблицу категорий и таблицу соединений с product_id, category_id и Score будет работать очень хорошо. Вам нужно будет либо назвать каждый столбец оценок (например, wedding_score и т. Д.) В объединении как псевдонимы, либо получить несколько возвращенных столбцов оценок (по одному для каждой категории).

Answer 1

РЕДАКТИРОВАТЬ: я не думаю, что есть категория стол и соединительный стол с product_id, category_id и оценка будет работать очень хорошо. Вы бы либо должны назвать каждый столбец оценки (например, wedding_score и т. д.) в соединении как псевдонимы или получить несколько столбцов оценки вернулся (по одному для каждой категории).

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

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

Answer 2

Вы на правильном пути. Иметь таблицу для «категории» с промежуточной таблицей с двумя столбцами, один PK для продуктов, другой PK для продукта; плюс треть за счет. Довольно стандартная картина. Тогда обычно промежуточная таблица имеет составной PK (например, productid + categoryid) и другой неуникальный индекс для categoryid.

Answer 3

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

Какие недостатки? Ну, у каждого предмета будет несколько записей, это правда. Это также не было бы так читаемо в браузере запросов. Но с правильными ключами и индексами было бы достаточно быстро использовать то, что вам нужно.