2013-12-02 4 views
0

Предположим, у меня есть пользователь. Пользователь может иметь несколько любимых цветов. Затем я разрешаю пользователям искать других пользователей с определенными любимыми цветами. Как я должен структурировать эту таблицу? Наличие таблицы с 20 столбцами для каждого цвета кажется плохой идеей, но попытка выполнить сопоставление строк в одном столбце также кажется очень запутанной.Rails: модель со многими опциями

Users 
id  name 
1  Don 


FavoriteColors 
id  user_id  red green blue orange violet... 
1  1   0  0  1  1   1 

И укороченные модели:

User 
    has_many :colors 

FavoriteColor 
    belongs_to :user 
+0

Почему у вас нет таблицы цветов. и color_id как внешний ключ? вы также можете иметь третью таблицу с user_id и color_id –

+0

@SamS, что было бы преимуществом для этой структуры над этим? –

+1

Производительность, обновления и поиск данных будут лучше. потому что он будет более нормализован. Google 1-я, 2-я и 3-я нормальные формы. Вы можете найти любимые цвета пользователей с простым объединением, но с дизайном у вас было бы намного сложнее –

ответ

0

взглянуть на 2.6 Ассоциация has_and_belongs_to_many здесь

The has_and_belongs_to_many Association Для многих многих отношениях это будет лучший вариант, поскольку он нормализуется ,

+0

Мне все еще кажется странным, потому что вместо 1 строки сопоставления в 1 строку (пользователь для FavoriteColors) теперь у меня есть 1 строка сопоставление со многими строками –

+0

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

Смежные вопросы