Должны ли пользователь и адрес находиться в отдельных таблицах?

Question

В настоящее время моя таблица пользователей имеет следующие поля:

Имя пользователя Пароль Имя Фамилия Город Адрес Страна Регион TelNo MobNo Электронная почта MembershipExpiry NoOfMembers DOB Пол Заблокировано UserAttempts BlockTime Отключено

Я не уверен, стоит ли помещать поля адреса в другую таблицу.Я слышал, что я сломаю 3NF, если я не сделаю, хотя я не могу понять почему.Может кто-нибудь объяснить, пожалуйста?

Answer 1

Есть несколько пунктов, которые определенно не являются 3NF;и некоторые сомнительные в дополнение:

1. Может ли быть несколько адресов на пользователя?
2. Является ли адрес необязательным или обязательным?
3. Дублирует ли информация в городе, стране, регионе ту же информацию, что и в адресе?
4. Может ли пользователь иметь несколько TelNos?
5. Является ли TelNo необязательным или обязательным?
6. Может ли пользователь иметь несколько MobNo?
7. Является ли MobNo необязательным или обязательным?
8. Может ли пользователь иметь несколько электронных писем?
9. Является ли электронная почта необязательной или обязательной?
10. Рассчитывается ли NoOfMembers из числа пользователей?
11. Может ли быть более одного UserAttempts?
12. Может быть большечем один BlockTime на пользователя?

Если ответ на любой из этих вопросов положительный, то это указывает на проблему с 3NF в этой области.Причиной 3NF является устранение дублирования данных;обеспечить, чтобы обновления, вставки и удаления оставляли данные в согласованной форме;и минимизировать хранение данных - в частности, нет необходимости хранить данные как «пока не известно / неизвестно / пусто».

В дополнение к вопросам, заданным здесь, существует также вопрос о том, что составляетпервичный ключ для вашей таблицы - я думаю, это как-то связано с пользователем, но имя и другая информация, которую вы предоставляете, вряд ли будут уникальными, поэтому их будет недостаточно для PK.(Если вы считаете, что имя плюс фамилия уникальны, вы предполагаете, что у вас никогда не будет более одного Джона Смита?)

РЕДАКТИРОВАТЬ: В свете дополнительной информации о том, что некоторые поля являются необязательными, я бы предложил вам отделитьВыделите необязательные поля в разные таблицы и установите 1-1 ссылки между новыми таблицами и пользовательской таблицей.Эта ссылка будет создана путем создания внешнего ключа в новой таблице, ссылающегося на первичный ключ пользовательской таблицы.Как вы говорите, ни одно из полей не может иметь несколько значений, тогда они вряд ли доставят вам проблемы в настоящее время.Однако если какое-либо из этих изменений изменится, то их отсутствие приведет к проблемам при обновлении приложения и данных для поддержки приложения.Вам все еще нужно решить проблему первичного ключа.

Answer 2

Пока каждый пользователь имеет один адрес и каждый адрес принадлежит одному пользователю, они должны быть в одной таблице (отношение 1 к 1).Однако, если пользователям не требуется вводить адреса (необязательное отношение), подойдет отдельная таблица.Кроме того, в нечетном случае, когда многие пользователи используют один и тот же адрес (например, они являются осужденными в одной и той же тюрьме), у вас есть отношение «один ко многим», и в этом случае отдельной таблицей будет путь.РЕДАКТИРОВАТЬ: И да, как кто-то указал в комментариях, если пользователи имеют несколько адресов (1-ко-многим наоборот), также должны быть отдельные таблицы.

Answer 3

Точно так же, как я думаю, что кто-то может помочь кому-то в этом вопросе, у меня когда-то была ситуация, когда я помещал адреса прямо в таблицы user / site / company / etc, потому что я думал, зачем мне когда-либо более одного адреса дляих?Затем, после того, как мы завершили все, другому отделу было доведено до моего сведения, что нам нужна была возможность записать как адрес доставки, так и адрес для выставления счета.

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

В наше время, я думаю, телефонные номера не представляют никакой сложности, и их следует хранить в отдельной таблице.У всех есть мобильные номера, домашние номера, рабочие номера, номера факсов и т. Д., И даже если вы планируете запросить только один, люди все равно оставят два в поле и разделят их точкой с запятой (поверьте мне).Просто еще кое-что, что нужно учитывать при разработке базы данных.

Answer 4

Дело в том, что если вы представляете, что в будущем у одного и того же пользователя будет два адреса, вам нужно разделить сейчас и иметь таблицу адресов с FK, указывающей назад на таблицу пользователей.

PS Ваша таблицаотсутствует идентификатор для использования в качестве PK, что-то вроде Id или UserId или DataId, назовите его так, как вы хотите ...

Answer 5

Добавив их в отдельную таблицу, вам будет проще расширить приложение, если вы решите сделать это позже. У меня обычно есть простая пользовательская таблица с user_id или id, user_name, first_name, last_name, password, creation_at & updated_at. Затем у меня есть таблица профиля с другой информацией.

Хотя это действительно все предпочтения.