Дизайн базы данных для определения значения по данным, предоставленным пользователем

Question

Я создаю обзорный сайт, на котором определенные сведения о продукте определяются на основе совокупных ответов пользователей, написавших отзыв о конкретном продукте.Например, когда пользователь просматривает продукт Macbook Air, кроме того, что он оценивает его на 1–5 звездочек и пишет описание своего опыта на 300 слов с помощью ноутбука, он также может сделать короткий «опрос», содержащий флажки, где он может выбратьпродукт рекомендуется для:

1. офисного пакета
2. игр
3. графического дизайна
4. просмотра фильмов

ДляНапример, пользователь может установить флажок «офисный пакет» и «просмотр фильмов».Предположим, что все ответы всех рецензентов на этот продукт Macbook Air дают 100 голосов за «офисный пакет» и 50 голосов, 20 голосов и 10 голосов за другие варианты.Поскольку опция «офисный пакет» имеет наибольшее количество голосов, на странице продукта Macbook Air будет указано:

Product recommended for: Office Suite

Как вы будете заниматься разработкой базы данных для этого?Я думаю о том, чтобы иметь отдельную таблицу со столбцами «rec_office_suite», «rec_games», «rec_graphic_design», «rec_watching_movies», каждый из которых содержит количество голосов за эту опцию.Каждый раз, когда рецензент отправляет свой отзыв и заполняет мини-опрос, таблица базы данных будет обновляться с полями, которые он выбрал для увеличения +1.

Дело в том, что это может привести к появлению таблицы со многими полями.Будет ли это проблемой?

Answer 1

Я бы порекомендовал комбинацию предложенного вами решения в вопросе и метода Нобиты.

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

Однако, когда дело доходит до отображения результатов на каждой странице продукта, в базе данных будет довольно сложно подсчитать все голоса по всем категориям для каждого продукта. Поэтому имеет смысл дублировать данные в своего рода кеш для быстрого чтения. Однако ваше представление о столбце таблицы для каждой категории будет нелегко расширить, и оно может стать очень большим. Вместо этого я просто сохранил бы голоса в столбце MEDIUMTEXT (или аналогичном) в таблице продуктов - возможно, в формате JSON или сериализованном массиве PHP - который очень просто читать. Обновление кэша необходимо только в том случае, если кто-то добавляет голос категории или когда добавляется новая категория.

Используя оба варианта, вы получаете легкий доступ к данным о товаре / категории / голосовании для более сложных запросов SQL в дальнейшем и быстрые запросы к страницам товара.

Надеюсь, что это имеет смысл, полусонный:)

Answer 2

Я бы сделал следующее, но давайте посмотрим, что люди рекомендуют:

1. Создайте таблицу с тремя полями: Product_ID - Category_ID - Голосов
2. Каждый раз, когда пользователь голосует заэта категория в поле голосования приращения продукта в приведенной выше таблице.

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

Надеюсь, это поможет.