Разработка базы данных для рейтинговой системы - PullRequest
3 голосов
/ 09 апреля 2009

Приложение обрабатывает пользователей и объекты, пользователи оценивают объекты с 3 функциями (по одной оценке на функцию).

РЕДАКТИРОВАТЬ : последнее предложение неясно: под характеристиками я понимаю критерии, общие для всех объектов

Насколько эффективно спроектировать базу данных для такой системы? Каковы лучшие практики для разработки базы данных, имеющей дело с системой рейтинга?

о чем я думал:

Таблица:

  • Пользователи
  • объекты
  • feat1rates
  • feat2rates
  • feat3rates

и отношения: У объекта много

  • feat1rates
  • feat2rates
  • feat3rates

У пользователя много

  • feat1rates
  • feat2rates
  • feat3rates

Ответы [ 3 ]

8 голосов
/ 09 апреля 2009

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

Таким образом, у вас есть таблица «Пользователи», таблица «Объекты» и таблица «Рейтинги», в которой в качестве объединенного первичного ключа используются идентификаторы пользователей и идентификаторы объектов. Таким образом, вы применяете одну оценку на объект на стандарт пользователя.

7 голосов
/ 09 апреля 2009

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

Я бы создал следующие таблицы:

Пользователь - базовая информация пользователя: логин, пароль, идентификатор пользователя, все, что вам нужно.

Объект - объект для оценки: его имя / идентификатор и атрибуты.

Feature - таблица, описывающая тип функции, с каким-либо именем / идентификатором функции. Это может начаться с ваших трех основных типов, но вы всегда можете расширить / изменить это. Вы также можете настроить, какие функции будут доступны каждому объекту для оценки.

ObjectFeature - таблица связей для объекта и объекта. Содержит первичный ключ каждой таблицы, создавая отношение «многие ко многим» между ними.

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

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

4 голосов
/ 09 апреля 2009

Очень странный дизайн, надо сказать. Рассмотрим:

Object: ID, ...

// Provided features cannot be shared between objects
ObjectFeature: ID, ObjectID, ... 

User: ID, ...

UserObjectFeatureRating: UserID, ObjectFeatureID, Rating
...