Должен ли пользователь и адрес быть в отдельных таблицах?
В настоящее время моя таблица пользователей имеет следующие поля
Я не уверен, должен ли я поместить поля адреса в другую таблицу. У меня есть слышал, что я буду ломать 3NF, если я этого не сделаю, хотя я не могу понять, почему. Кто-нибудь может объяснить?
5 ответов
есть несколько пунктов, которые определенно не 3NF; и некоторые сомнительные, кроме того:
- может ли быть несколько адресов на одного пользователя?
- является ли адрес необязательным или обязательным?
- дублирует ли информация в городе, стране, регионе адрес?
- может ли пользователь иметь несколько TelNos?
- является ли TelNo необязательным или обязательным?
- может ли пользователь иметь несколько MobNos?
- - Это MobNo необязательный или обязательный?
- может ли пользователь иметь несколько электронных писем?
- - Это письмо, факультативный или обязательный?
- вычисляется ли NoOfMembers из числа пользователей?
- может ли быть более одного UserAttempts?
- может ли быть более одного BlockTime на пользователя?
Если ответ на любой из этих вопросов да, то это указывает на проблему с 3НФ в этой области. Причина 3NF заключается в устранении дублирования данных; убедитесь, что обновления, вставки и удаления оставляют данные в согласованной форме; и свести к минимуму хранение данных - в частности, нет необходимости хранить данные как "еще не известно/неизвестно/null".
в дополнение к вопросам, заданным здесь, есть также вопрос о том, что представляет собой первичный ключ для вашей таблицы - я бы предположил, что это что-то связано с пользователем, но имя и другая информация, которую вы даете, вряд ли будут уникальными, поэтому не будет достаточно как ПК. (Если вы думаете имя плюс фамилия уникальна вы предполагаете, что у вас никогда не будет более одного Джона Смита?)
изменить: В свете дополнительной информации о том, что некоторые поля являются необязательными, я бы предложил разделить необязательные поля на разные таблицы и установить 1-1 связи между новыми таблицами и таблицей пользователя. Эта ссылка будет создана путем создания внешнего ключа в новой таблице, ссылающийся на первичный ключ таблицы пользователей. Как вы говорите, ни одно из полей может иметь несколько значений, то они вряд ли дадут вам проблемы в настоящее время. Если, однако, любое из этих изменений, то не разделяя их даст вам проблемы в обновлении приложения и данных для поддержки приложения. Вам все еще нужно решить проблему первичного ключа.
пока каждый пользователь имеет один адрес и каждый адрес принадлежит одному пользователю, они должны идти в одной таблице (отношение 1 к 1). Однако, если пользователям не требуется вводить адреса (необязательная связь), будет уместна отдельная таблица. Кроме того, в нечетном случае, когда многие пользователи имеют один и тот же адрес (например, они осужденные в одной тюрьме), у вас есть отношение "1 ко многим", и в этом случае отдельная таблица будет способом пойти. EDIT: и да, как кто-то указал в комментариях, если у пользователей несколько адресов (от 1 до многих наоборот), также должны быть отдельные таблицы.
дело в том, что если вы предполагаете иметь два адреса для одного и того же пользователя в будущем, вы должны разделить сейчас и иметь таблицу адресов с FK, указывающую на таблицу пользователей.
P.S. В вашей таблице отсутствует идентификатор, который будет использоваться как PK, что-то вроде Id или UserId или DataId, назовите его так, как вы хотите...
Так же, как я думаю, что может помочь кому-то в этом вопросе, у меня когда-то была ситуация, когда я помещал адреса прямо в таблицы user/site/company/etc, потому что я думал, зачем мне когда-либо нужно больше одного адреса для них? Затем, после того, как мы закончили все это, мое внимание было привлечено другим отделом, что нам нужна возможность записи как адреса доставки, так и адреса выставления счетов.
мораль истории в том, что это частое требование, поэтому, если вы думаете, что вы когда-нибудь запишите доставка и адреса выставления счетов, или может думать о любом другом типе адреса вы можете записать для пользователя, идти вперед и положить его в отдельную таблицу.
в сегодняшнем возрасте, я думаю, что телефонные номера не мудренее, а также должны храниться в отдельной таблице. У каждого есть мобильный номер, домашний, номера рабочий, факс, и т. д., и даже если вы планируете просить только один, люди все равно поставят два в поле и разделите их точкой с запятой (поверьте мне). Просто что-то еще, что нужно учитывать в дизайне базы данных.
добавив их в отдельную таблицу, вам будет легче расширить свое приложение, если вы решите позже. Обычно у меня есть простая таблица пользователя с user_id или id, user_name, first_name, last_name, password, created_at & updated_at. Затем у меня есть таблица профиля с другой информацией.
его действительно все предпочтения, хотя.