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