Структура реляционной базы данных для хранения нескольких увлечений пользователя

Question

Я пытаюсь зарегистрировать некоторых пользователей с основными сведениями, такими как имя пользователя / адрес электронной почты, пароль, и их увлечениями, такими как чтение, спорт, танцы и т. Д., А затем отображать пользователей с аналогичными увлечениями. Текущая схема выглядит примерно так:

Users

 - id 
 - email 
 - password 
 - country 
 - hobbies_id

hobbies

 - id 
 - user_id 
 - sports(values true/false) 
 - reading(values true/false)
 - dance(values true/false)

Каждое хобби размещается в виде столбца в таблице хобби.

Какая схема будет наиболее оптимизированной, если я увеличу количество увлечений с 3 до 20? Кроме того, может ли кто-нибудь помочь мне с запросом, чтобы выбрать пользователей с подобными хобби / хобби? Например, если Джон любит читать и заниматься спортом, а Ким любит спорт и танцы, то у них спорт - обычное хобби.

Заранее спасибо.

Answer 1

мы можем сделать с двумя решениями: *

• @ Решение GMB
• убрал таблицу хобби и сохранил данные хобби только в пользовательской таблице, в типе данных json.

Answer 2

Следуя комментариям @Madhur Bhaiya, я бы назвал это тремя таблицами:

users
 - id 
 - email 
 - password 
 - country 

hobbies
 - id
 - name (sports, reading, dance, ...)

user_hobbies
 - user_id
 - hobbie_id

Таблица users является основной таблицей для пользователей (одна запись на пользователя).

Таблица hobbies является главной таблицей для хобби (одна запись на хобби). Когда создаются новые хобби, вам не нужно создавать новые столбцы, просто добавьте новые строки.

Таблица user_hobbies отображает пользователей на хобби: она содержит одну запись для каждого набора user_id/hobbie_id.

Answer 3

Для этого я бы рекомендовал посмотреть Нормализация базы данных . Эта проблема должна быть решена путем внедрения Третьей нормальной формы (TNF). Для этого вы должны удалить hobby_id из таблицы users и удалить user_id из таблицы hobbies. Нормализованным примером одного решения этой проблемы было бы создание новой таблицы, которая использует user_id и hobby_id в качестве составного ключа. См. Ниже:

users:
  - id
  - email
  - password
  - country

user_hobby:
  - user_id
  - hobby_id

hobbies:
  - id
  - description
  - type

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