Дизайн таблицы для получения информации пользователя, а также данных для входа в систему?
Первоначально я хотел бы попросить, чтобы Вы забыли о хешировании паролей или w/e, связанного с паролями, этот вопрос не связан с обеспечением паролей, и т.д. и я действительно знаю/понимаю, как это должно быть сделано.
Что лучший подход должен хранить данные рассматриваемая, рассматривающая производительность на чтении-записи - для создания одной или нескольких таблиц?
Единственная таблица, например:
Пользователи таблицы: идентификатор, имя пользователя, пароль, хеш, электронная почта, группа, доступ, адрес, телефон, родители, ts_created, ts_update
Несколько таблиц, например:
Пользователи таблицы: идентификатор, имя пользователя, пароль, хеш, электронная почта, группа, доступ, ts_created, ts_update
Информация пользователя таблицы: идентификатор, user_id, адрес, телефон, родители, ts_created, ts_update
Что, если информационные поля Вашего пользователя могут вырасти вдоль времени - как необходимо иметь дело с ним?
Например, новые поля: birthday_date, комментарии, ситуация
Будет наличие 2 таблиц быть медленнее на запросах, чем наличие единственной таблицы?
Если наличие нескольких таблиц в этом случае только для поддержания хорошего дизайна с разделенными данными, которые означают, что это не полезно вообще по причинам производительности?
Если Вы хотите реальные sql сообщенные мне примеры, и я фрагментирую что-то для обновления этого.
2 ответа
Вам может потребоваться еще больше таблиц в зависимости от данных, которые вы собираетесь хранить:
- Что делать, если вы используете политику паролей в будущее, в котором пользователь не может повторно использовать ранее использованный пароль?
- Может ли пользователь иметь более одного адреса электронной почты?
- Может ли пользователь принадлежать более чем к одной группе?
- Может ли пользователь иметь более одного номера телефона?
- Только один родитель? Или два? Родитель в системе? Какую информацию о родителе вы храните?
Хранение подобных мыслей, возможно, стоит хранить в отдельной отдельной таблице, а это значит, что в будущем ее будет намного проще поддерживать. Вам нужно подумать о том, как изменится система. Что касается производительности, как уже отмечалось, это не должно быть проблемой, если вы создаете правильные индексы и правильно используете базу данных.
Ваш многотабличный дизайн выглядит разумным - одна таблица содержит данные о пользователе, другая - о человеке; если вам нужны только пользовательские данные (например, для проверки прав доступа), личные данные не имеют значения.
Новые поля, которые вы предлагаете, вероятно, войдут в таблицу person в виде новых столбцов.
Использование 2 (или более) таблиц и их объединение существенно не замедлит вас - это может даже улучшить производительность (при хорошем индексировании - уникальный индекс для user_id здесь будет хорошим началом):
- on SELECT , разница в скорости будет незначительной
- при INSERT / UPDATE, это будет лучше, чем отдельная таблица в большинстве ситуаций (например, если таблица "users" имеет много чтений, записи для людей не будут блокировать их - тогда как с одним table, это может случиться)
Кроме того, лично мне намного проще (как в коде, так и в администрировании базы данных) работать с двумя более узкими таблицами, чем с одной широкой таблицей.