Дизайн таблицы для пользовательской информации, а также учетные данные для входа?

Вначале я хотел бы попросить вас забыть о хэшировании паролей или w/e, связанных с паролями, этот вопрос не связан с обеспечением паролей и т.д., и я знаю/понимаю, как это должно быть сделано.

Каков наилучший подход для хранения данных, о которых идет речь, учитывая производительность при чтении/записи - для создания одной или нескольких таблиц?

Отдельная таблица, например:

Пользователи таблицы: идентификатор, имя пользователя, пароль, хэш, электронная почта, группа, доступ, адрес, телефон, родители, ts_created, ts_update

Несколько таблиц, например:

Пользователи таблицы: идентификатор, имя пользователя, пароль, хэш, электронная почта, группа, доступ, ts_created, ts_update

Информация о пользователе в таблице: id, user_id, адрес, телефон, родители, ts_created, ts_update

Что делать, если ваши информационные поля пользователя могут расти вместе с вами - как вы должны с этим справиться?

Например, новые поля: birthday_date, комментарии, ситуация

Будет ли иметь 2 таблицы медленнее запросов, чем одна таблица?

Если в этом случае несколько таблиц предназначены только для поддержания хорошего дизайна с разделенными данными, означает ли это, что это не полезно вообще по соображениям производительности?

Если вы хотите, чтобы реальные примеры sql давали мне знать, и я откажусь от чего-то, чтобы обновить это.

Ответ 1

Вам может потребоваться еще больше таблиц в зависимости от данных, которые вы собираетесь хранить:

Что делать, если вы используете политику паролей в будущее, когда пользователь не может повторно использовать ранее использованный пароль?
Может ли пользователь иметь более одного электронного письма?
Может ли пользователь принадлежать к нескольким группам?
Может ли пользователь иметь более одного номера телефона?
Только один родитель? Или два? Является ли родительский элемент в системе? Какую информацию о родителе вы храните?

Хранение таких идей может стоить хранить в отдельной таблице, а это значит, что в будущем это будет намного проще в обслуживании. Вам нужно подумать о том, как изменится система. Что касается производительности, как уже было указано, это не должно быть проблемой, если вы создаете правильные индексы и правильно используете базу данных.

Ответ 2

Ваш дизайн с несколькими таблицами выглядит разумно - одна таблица содержит данные о пользователе, а другая - о человеке; если вам нужны только данные пользователя (например, для проверки прав доступа), данные пользователя неактуальны.

Новые поля, которые вы предлагаете, вероятно, войдут в таблицу лиц в качестве новых столбцов.

Использование 2 (или более) таблиц и объединение их вместе не замедлит вас - это может даже повысить производительность (при хорошем индексировании - уникальный индекс для user_id будет хорошим началом здесь):

в SELECT, разница в скорости будет незначительной.
в INSERT/UPDATE, это будет лучше, чем одна таблица в большинстве ситуаций (например, если таблица "users" имеет много чтений, записи на лицах не будут блокировать их, тогда как с одной таблицей это может произойти)

Кроме того, лично мне гораздо проще (как в коде, так и в администрировании db) работать с двумя более узкими таблицами, чем с одной широкой таблицей.