Страница профиль Use Case

Question

На странице профиля сайта содержит эти виды полеев для любого пользователя

1. один к одному полею - имя, возраст, пол
2. One для многих областей - История работы, образование
3. многие ко многим полям - Язык, премии, комитет

Tools - MYSQL и PHP [но открыты для изменения]

Я решил создать одну пользовательскую таблицу.

tbl_user -> PK - user_id , FK - profile_id 

Все поля, которые происходят за один раз для пользователя, добавить их в качестве атрибутов таблицы tbl_user_profile.

tbl_user_profile -> PK - profile_id 

Тогда, чтобы удовлетворить один ко многим видам relatioships Я создаю кучу таблиц - Это легко может расти в течение периода времени ..

tbl_user_jobs , tbl_user_education 
FK - user_id [ INNO DB ] 

А потом я создаю кучу таблиц в виде таблиц реф для MANY_TO_MANY моделирования -

tbl_ref_awards, tbl_ref_languages, tbl_ref_committee 
PK = REF_ID 

tbl_user_languages, tbl_user_awards, tbl_user_committee 
FK - user_id , REF_ID 

Теперь я должен отобразить страницу профиля с, как многие де только что упомянутые хвосты. На странице загружается каждый раз, мне нужно присоединить таблицы tbl_user_ * таблицы с tbl_user и заполнить страницу.

Я размышляю, если этот дизайн в порядке в первую очередь? Во-вторых, с таким количеством таблиц, которые соединяются [7 раз] на странице, я вижу перетаскивание уже при загрузке страницы, и было бы очень приятно услышать о возможном улучшении дизайна базы данных в приведенном выше примере использования. Уже есть индексы и FK. Кэш еще не добавил нигде.

Answer 1

Это довольно разумный подход к моделированию ваших данных; единственный комментарий, который я сделал бы, заключается в том, что вместо того, чтобы называть первичный ключ для ваших ссылочных таблиц «REF_ID», я бы назвал их после самой таблицы - например, award_id. Тоже для внешних ключей.

Это, конечно, вопрос предпочтения, но он более согласован - вы назвали первичный ключ таблицы профилей пользователя «profile_id».

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

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

user_id user_name job_name language_name 
------------------------------------------- 
1  Bob   Waiter French 
1  Bob   Waiter German 
1  Bob   Waiter Italian 
1  Bob   Plumber French 
1  Bob   Plumber German 
1  Bob   Plumber Italian 

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