MYSQL: настройка таблицы сведений о профиле пользователя - лучшая практика

Рядом с вашей обычной пользовательской таблицей "пользователь" (user_id/user_email/user_pwd/etc), что лучше всего подходит для хранения информации о профиле?

Можно ли добавить поля в пользовательскую таблицу, например "пользователь"

(user_id/user_email/user_pwd/user_firstname/user_lastname/user_views/etc)

или создать другую таблицу с именем "профили"

(profile_id/user_id/user_firstname/user_lastname/user_views/etc)

или можно будет найти таблицу с определениями свойств и другую таблицу для хранения этих значений?

Я знаю, что последняя является самой гибкой, так как вы можете легко добавлять и удалять поля. Но для большого сайта (50 тыс. Пользователей) это будет быстро?

Ответ 1

Вещи, которые следует учитывать с вашими подходами

Сохранение профиля пользователя в таблице пользователей

Это, как правило, самый быстрый способ получения данных профиля, хотя у вас может быть много избыточных данных здесь (столбцы, которые могут не иметь в них никакой информации).
Быстрое (особенно, если вы только извлекаете столбцы из db)
Отработанные данные
Сложнее работать/поддерживать (возможно, с интерфейсами, такими как PHPMyAdmin)

Сохранение профиля пользователя в User_Profile Таблица 1-1 отношение к пользователям

Должно быть довольно быстро с соединением, и вы можете устранить избыточность данных, если профили пользователей не создаются, если пользователь не заполняет их.
Легче работать с
С таким чуть-чуть медленным из-за соединения (или второго запроса)

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

* т.е. Таблица для хранения возможных опций, таблица для хранения user_id, option_id и значение *

Нет избыточных данных, все данные релевантно
Самый нормализованный метод
Медленнее получать и обновлять данные

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

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

Ответ 2

Таблица с определениями свойств не является хорошей идеей. Я предлагаю использовать три таблицы для хранения данных:

user(id,login,email,pwd, is_banned, expired, ...) 
-- rarely changed, keep small, extremaly fast search, easy to cache, admin data
profile(id, user_id, firstname,lastname, hobby,description, motto)
--data often changed by user,...    
user_stats(id,user_id,last_login,first_login,post_counter, visit_counter, comment_counter)
--counters are very often updated, dml invalidate cache

Лучшим способом хранения данных авторизации и аутентификации является LDAP.

Ответ 3

Вам понадобится более трех таблиц. Как он будет хранить данные, такие как несколько электронных писем, несколько адресов, несколько образовательных историй, множественные "поиски" отношений и т.д. Каждый из них нуждается в собственной строке, предполагая, что многие значения будут выглядеть как город, предпочтения полов, названия школ и т.д., Так что либо нормализуйте он полностью или идет по пути noSQL, нет смысла висеть посередине, вы потеряете лучшее из обоих миров.

вы можете дублировать строки, но это не будет хорошо. социальные сети не живут с 50 000 пользователей. либо вы добьетесь успеха, и у вас будет миллионы пользователей, или вы столкнетесь с ним, и вы должны будете его убить, потому что для запуска их вам потребуется $$$, который появится только в том случае, если у вас есть прочная база пользователей. Поскольку только 50 000 пользователей для жизни инвесторы не инвестируют, доходы от рекламы не покрывают расходы, и вы ее закроете. Так что спроектируйте его так, как будто вы хотите стать следующей facebook с самого первого дня. Подумайте, большой!