Рядом с вашей обычной пользовательской таблицей «пользователь» (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 тыс. Пользователей) это будет быстро?
Что нужно учитывать при ваших подходах
Сохранение профиля пользователя в таблице пользователей
Сохранение профиля пользователя в User_Profile Таблица 1-1 отношение к пользователям
Сохранение профиля пользователя в качестве свойств и значений в таблицах
* т.е. Таблица для хранения возможных опций, таблица для хранения user_id, option_id и значение *
Мое впечатление, что большинство веб-сайтов используют второй метод и хранят данные профиля во второй таблице, его общий для большинства крупных веб-сайтов для де-нормализации базы данных (твиттер, facebook) для достижения большей производительности чтения за счет более низкой производительности записи.
Я думаю, что сохранение информации профиля во второй таблице, скорее всего, будет идти, когда вы смотрите 50 000 записей. Для обеспечения оптимальной производительности вы хотите сохранить данные, которые сильно отличаются от данных, которые считаются тяжелыми, чтобы обеспечить эффективную работу кеша.
Таблица с определениями свойств не является хорошей идеей. Я предлагаю использовать три таблицы для хранения данных:
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.
Вам нужно больше трех таблиц. Как он будет хранить данные, такие как несколько электронных писем, несколько адресов, несколько образовательных историй, множественные «поиски» отношений и т. Д. Каждый из них нуждается в собственной строке, предполагая, что многие значения будут выглядеть как город, предпочтения полов, названия школ и т. Д., Так что либо нормализуйте он полностью или идет по пути noSQL, нет смысла висеть посередине, вы потеряете лучшее из обоих миров.
вы можете дублировать строки, но это не будет хорошо. социальные сети не живут с 50 000 пользователей. либо вы добьетесь успеха, и у вас будет миллионы пользователей, или вы столкнетесь с ним, и вы должны будете его убить, потому что для запуска их вам потребуется $$$, который появится только в том случае, если у вас есть прочная база пользователей. Поскольку только 50 000 пользователей для жизни инвесторы не инвестируют, доходы от рекламы не покрывают расходы, и вы ее закроете. Так что спроектируйте его так, как будто вы хотите стать следующей facebook с самого первого дня. Подумайте, большой!