Многие ко многим дизайн базы данных вопрос

Question

, у вас есть следующие многие-ко-многим таблицы соотношения:

user 
----- 
id 
first_name 
last_name 

user_prefs 
---------------- 
id 
preference_name 

user2user_prefs 
------------- 
id 
user_id 
user_pref_id 

Но говорят, у вас есть предпочтения пользователя на «домашнюю страницу» и нужно где-то хранить фактическую домашнюю страницу URL-адрес. Где это будет?

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

Я могу поставить его в user2user_prefs так:

user2user_prefs 
------------- 
id 
user_id 
user_pref_id 
value 

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

Спасибо! Stabby L

Answer 1

Вы должны посмотреть на функциональные зависимости. Значение не зависит от пользователя, оно не зависит от userpref, но оно зависит от обоих. Это подразумевает, что вам нужно поместить его в tab2 пользователя user2user_prefs, как вы предложили.

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

Answer 2

Я не могу поставить значение в user_prefs , потому что то же самое значение будет применяться ко всем, кто имеет что отображение.

Вы нормализуете слишком далеко. Домашняя страница будет в порядке user_prefs.

В самом деле, если бы я тебя, я бы использовал только одну таблицу:

user 
----- 
id 
first_name 
last_name 
homepage 
<other settings> 

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

Answer 3

Мне кажется, что особый тип значения на самом деле не относится к отношениям многих-многих. Если конкретное значение свойства специфично для каждого пользователя, то, похоже, это должна быть отдельная таблица. Он «чувствует», как будто бы было отношение 1-много от user к другой таблице, у которой есть предпочтения, уникальные для каждого пользователя.

Edit: Для 1 ко многим таблице:

user_specific_prefs 
------ 
id 
user_id 
pref_name (or possibly pref_id that indicates the type) 
pref_value (store www.myhome.com for example) 

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

Answer 4

Вы очень близко.

[Изменить: Мой ранее считавшийся блестящим ответом был не таким блестящим.]

Отредактированные столы:

users 
----- 
id 
first_name 
last_name 
preferences 

Поле предпочтений будет держать упорядоченный объект или массив конкретных вариантов пользователей. В PHP:

if (is_array($options) || is_object($options)) 
     serialize($options); 

Serialize Manual