Блог

Главная - Вопросы по программированию - моделирование базы данных -mysql

моделирование базы данных -mysql

#mysql #database #database-design

#mysql #База данных #база данных-дизайн

Вопрос:

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

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

спасибо за ваше время

Ответ №1:

Если:

  1. У всех (или почти всех) пользователей все данные заполнены
  2. Большую часть времени вы запрашиваете все поля

тогда храните их в одной таблице, иначе они разделятся.

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

Адрес, возраст, фотография и должность обычно отображаются вместе с именем пользователя, поэтому было бы лучше объединить их в одну таблицу.

Комментарии:

1. в моей модели я всегда проверяю при входе в систему, активирована учетная запись или нет.

2. @Wire: конечно, но вам действительно нужно хранить ссылку активации вечно после того, как она была использована? Я бы создал 1 байт isActive BOOL и отбросил ссылку после того, как была выполнена активация.

3. у меня есть логическое значение для активированного или неактивированного. ссылка через день или два может быть удалена, да 🙂

Ответ №2:

Не позволяйте вашему первоначальному дизайну ограничивать возможности (или просто затруднять) расширения ваших требований в будущем.

  • На данный момент у пользователя может быть один, address поэтому вы могли бы поместить его в users таблицу — что, если вы хотите, чтобы они могли хранить «рабочие» и «домашние» адреса в будущем или историю прошлых адресов?
  • Пользователю может быть разрешено иметь только одну фотографию, но если вы поместите ее (или URL для нее) в users.photo , вам придется изменить структуру данных, чтобы разрешить пользователю иметь историю фотографий профиля

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

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