Проблема дизайна базы данных - несколько баллов в разных категориях
Скажем, у меня есть база данных товаров одежды. В дополнение ко многим другим полям в базе данных должны храниться рейтинги (баллы из 10) по различным категориям для каждого продукта.
Например, одна категория может быть "поводом". Случаи могут быть следующими:
Носить в офис Носить на свадьбу Носить на свидание... Носить на похороны
Каждому продукту нужно присвоить 10 баллов для каждого из них. Таким образом, один продукт может иметь:
Отделение: 5 Свадьба: 7 Дата: 10 Похороны: 0
Что указывало бы на то, что предмет - это что-то веселое, не слишком преуменьшенное, возможно, не слишком формальное
Есть несколько категорий, подобных этой, и они будут использоваться как часть алгоритма поиска, поэтому скорость может быть проблемой. Кроме того, я не хочу, чтобы моя таблица продуктов стала огромной. Это означает, что мне непросто хранить это в таблице продуктов, поскольку каждый ответ имеет свой собственный столбец.
Возможно, хранить таким образом, кроме как в другой таблице с объединением? Просто ищу достаточно гибкое и элегантное решение.
Если я не был ясен, пожалуйста, дайте мне знать.
PS Использую MySQL, если это имеет значение...
РЕДАКТИРОВАТЬ: я не думаю, что иметь таблицу категорий и таблицу соединений с product_id, category_id и счет будет работать очень хорошо. Вам нужно будет либо назвать каждый столбец оценок (например, wedding_score и т. Д.) В объединении как псевдонимы, либо получить несколько возвращенных столбцов оценок (по одному для каждой категории).
3 ответа
РЕДАКТИРОВАТЬ: я не думаю, что иметь таблицу категорий и таблицу соединений с product_id, category_id и счет будет работать очень хорошо. Вам нужно будет либо назвать каждый столбец оценок (например, wedding_score и т. Д.) В объединении как псевдонимы, либо получить несколько возвращенных столбцов оценок (по одному для каждой категории).
Я думаю, что это путь, потому что он позволяет вам одинаково относиться к различным оценкам. Большая часть вашего кода не нуждается в корректировке, когда тип счета добавляется, переименовывается, удаляется и т. Д.
Если вы беспокоитесь о сложных объединениях для объединения этой информации, возможно, один или два представления помогут.
Вы на правильном пути. Иметь таблицу для "категории" с промежуточной таблицей с двумя столбцами, один PK для продуктов, другой PK для продукта; плюс треть за счет. Довольно стандартная картина. Тогда обычно промежуточная таблица будет иметь составной PK (например, productid + categoryid) и другой неуникальный индекс для categoryid.
Что ж, реляционная база данных оптимизирована для хранения отношений, поэтому таблица для хранения описаний элементов, другая для категорий оценки (включая описание оценки) и объединяющая таблица (элемент для оценки) кажется идеальным ответом.
Какие недостатки? Ну, у каждого предмета будет несколько записей, это правда. Это также не было бы так читаемо в браузере запросов. Но с правильными ключами и индексами было бы достаточно быстро использовать то, что вам нужно.