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

Question

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

1. Что делать, если вы используете политику паролей в будущее, где пользователь не может повторно использовать ранее использованный пароль?
2. Может ли пользователь иметь более одного электронного письма?
3. Может ли пользователь принадлежать к нескольким группам?
4. Может ли пользователь иметь более одного номера телефона?
5. Только один родитель? Или два? Родитель в системе? Какую информацию о родителе вы храните?

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

Answer 2

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

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

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

• при выборе, разница в скорости будет незначительной
• в INSERT / UPDATE, это будет лучше, чем одна таблица в большинстве ситуаций (например, если таблица «users» имеет много чтений, записи о людях не будут их блокировать - тогда как с одной таблицей это может произойти) 1010 *

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