Лучший способ хранить переменное количество предпочтений? - PullRequest
2 голосов
/ 08 апреля 2011

Мне нужно хранить переменное количество пользовательских настроек.Например, если мы говорим о фильмах, пользователь 1 любит фильмы [A, B, C], а пользователь 2 любит [C, D] и т. Д. Какой лучший способ хранить их в таблице «правильно» - так что я могуэффективно выполнять поиск по этим предпочтениям, не иметь множества таблиц, если есть новые типы предпочтений и т. д.

Ответы [ 5 ]

6 голосов
/ 08 апреля 2011

Имеется одна таблица с пользователями , одна таблица с фильмами и третья таблица ( предпочтения ), где вы сопоставляете пользователя с фильмом. Таким образом, пользователю может понравиться несколько фильмов, а разным пользователям может понравиться один и тот же фильм. Это в основном отношения M: N. Это то, что вы ищете?

3 голосов
/ 08 апреля 2011

Я предлагаю вам взглянуть на модель Entity-Attribute-Value .
Это обеспечивает большую гибкость в отношении изменений логической схемы и в отношении количества элементов.
Различные реализации и особенности EAV обсуждаются в сообщениях stackoverflow , может быть, вы можете начать с этой , поскольку она обычно охватывает тип вопросов, задаваемых здесь.

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

Основными недостатками модели EAV являются несколько более сложная структура таблицы, а также потеря эффективности (скажем, с миллионами и более сущностями).
При простой реляционной модели модель данных более очевидна в [физической] схеме базы данных. Потеря эффективности происходит главным образом из-за того, что в таблице «Значения» хранится только одно значение атрибута за раз (что предотвращает создание комбинированных индексов и т. Д.), И она может быть довольно большой по сравнению с количеством записей, которые потребуются для ее хранения. данные в простой реляционной форме.

Редактировать (относительно производительности)
Я был относительно успешным с экземплярами данных до 4 миллионов строк каждая / большинство с дюжиной атрибутов в среднем. Точный «пробег», который мы можем из этого получить, зависит от разреженности данных и относительной селективности некоторых значений атрибутов. Существует несколько «хитростей», которые улучшают производительность за счет дальнейшего усложнения реализации:

  • хранение наиболее часто используемых общих атрибутов с единичным значением в таблице Entity, а не (или в дополнение к) таблице Values.
  • с использованием нескольких таблиц значений. Такие «разделы» могут управляться типом данных, диапазоном идентификаторов атрибутов ...
1 голос
/ 08 апреля 2011
-- Predicate: User has id number :user_id.
create table users (
  user_id integer primary key
);

-- Predicate: Movie has id number :movie_id and name :movie_name.
create table movies (
  movie_id integer primary key,
  movie_name varchar(150) not null  -- Movie names aren't unique.
);

-- Predicate: User :user_id likes to watch movie :movie_id.
create table movie_preferences (
  user_id integer references users (user_id),
  movie_id integer references movies (movie_id),
  primary key (user_id, movie_id)
);

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

-- Predicate: Restaurant has id number :restaurant_id and name :restaurant_name,
-- and is known for its :known_cuisine cooking.
create table restaurants (
  restaurant_id integer primary key,
  restaurant_name varchar(150) not null,
  known_cuisine varchar(30) not null
);

-- Predicate: User :user_id likes to eat at restaurant :restaurant_id.
create table restaurant_preferences (
  user_id integer references users (user_id),
  restaurant_id integer references restaurants (restaurant_id),
  primary key (user_id, restaurant_id)
);

Вам нужны дополнительные таблицы для дополнительных предпочтений, потому что фильмы - это не то же самое, что рестораны, и «мне нравится« Top Gun »» не означает то же самое, что «мне нравится Burger King». "

У вас не будет множества таблиц.У вас будет только одна таблица для каждого предпочтения.(Потому что вам придется создать таблицу ресторанов, чтобы можно было их идентифицировать, верно?)

0 голосов
/ 08 апреля 2011

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

По мере создания новых предпочтений они помещаются в таблицу с соответствующим идентификатором.

Затем создайте таблицу соединений (многие ко многим) с помощью

UserID
PreferenceID
0 голосов
/ 08 апреля 2011

редких столбцов!это именно то, для чего они были сделаны:

http://www.kodyaz.com/articles/sql-server-2008-sparse-columns.aspx

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...