Дизайн сайта базы данных Дружбы

Question

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

Решение # 1 - User стол:

id | age | birth day | City  | Gender | Education | fav Pet | fav hobbie. . . 
--------------------------------------------------------------------------  
0 | 38 | 1985  | New York | Female | University | Dog  | Ping Pong 

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

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

Решение # 2 - User стол:

id | age | birth day | City  | Gender | Education | fav Pet | fav hobbies 
-------------------------------------------------------------------------- 
0 | 38 | 1985  | New York | 0 |  0 |  0 |  0 

Pets стол:

id | Pet Type 
--------------- 
0 | Dog 

Кто-нибудь есть какие-либо идеи, как подойти к этой проблеме он чувствует, как оба ответа неверны. Каков правильный дизайн таблицы для этой базы данных?

Answer 1

Этого больше, чем кажется на первый взгляд: прежде всего - если у вас есть множество атрибутов, многие из которых, вероятно, будут нулевыми для любой конкретной строки и с очень динамичным выбором атрибутов (т.е. новые атрибуты будут появляются довольно часто во время жизненного цикла кода), вы можете спросить себя, является ли RDBMS лучшим способом материализации этого ... по существу не-схемы. Может быть, магазин документов лучше подходит?

Если вы хотите остаться в РСУБД мире, канонический ответ должен иметь либо один или один-в-типа данных таблицы свойств плюс таблица свойств:

Users.id | .name | .birthdate | .Gender | .someotherfixedattribute 
---------------------------------------------------------- 
1743  | Me. | 01/01/1970 | M  | indeed 


Propertytpes.id | .name 
------------------------ 
    234   | pet 
    235   | hobby 

Poperties.uid | .pid | .content 
----------------------------- 
1743   | 234 | Husky dog 

Answer 2

Вместо широкой таблицы с полем на атрибут или нескольких таблиц атрибутов, вы могли бы сделать тощую таблицу с большим количеством строк, что-то вроде:

Attributes (id,user_id,attribute_type,attribute_value) 

В конечном счете лучшее решение во многом зависит от того, как данные будет использован. У людей может быть только один DOB, но, возможно, вы хотите разрешить несколько адресов (биллинг/рассылка/и т. Д.), Поэтому адреса могут иметь отдельную таблицу.

Answer 3

У вас есть комментарий и ответ, которые рекомендуют (или, по крайней мере, предлагают) и модель Entity-Attribute-Value (EAV).

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

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