моделирование базы данных -mysql - PullRequest
2 голосов
/ 26 апреля 2011

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

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

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

Ответы [ 2 ]

2 голосов
/ 26 апреля 2011

Если:

  1. Все (или почти все) пользователи заполняют все данные
  2. В большинстве случаев вы запрашиваете все поля

, а затемхраните их в одной таблице, другие разделяют их.

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

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

1 голос
/ 26 апреля 2011

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...