Дизайн вставки SQL при использовании модульного адреса

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

Другие объекты в базе данных имеют столбец для AddressID (например, таблицы InsuranceCompany и BranchOffice и т. д.). Когда я вставляю новую строку в один из этих объектов, мне нужно указать AddressID. Мне интересно, как лучше всего это спроектировать? Могу ли я иметь представление со всеми различными типами информации (номер телефона, физический адрес и т. д.) в виде столбцов, а затем сначала выполнить вставку в представление и получить вывод AddressID для вставки в объект InsuranceOffice? Должен ли я использовать хранимую процедуру?

Table 1 - Address

   AddressID              int identity

Table 2 - PhoneNumber

   AddressID              int
   PhoneNumber            varchar(10)

Table 3 - PhoneNumberForeignPart

   AddressID              int
   CountryCode            varchar(5)
   PhoneNumberSuffix      varchar(5)

Table 4 - PhoneNumberExtenstion

   AddressID              int
   PhoneNumberExtension   varchar(5)

Table 5 - EmailAddress

   AddressID              int
   EmailAddress           varchar(50)

...

Table 10 - InsuranceCompany

   InsuranceCompanyID     int identity
   InsuranceCompanyName   varchar(40)
   AddressID              int
   Disabled               bit

Спасибо.


person ffrugone    schedule 27.05.2016    source источник
comment
Честно говоря, я не думаю, что пришло осознание того, насколько головной болью будет поддерживать эту структуру. Если вам нужна таблица адресов, поместите в нее все столбцы, связанные с физическим адресом (улица, город, штат, страна, телефон и т. д.). Затем используйте внешний ключ, как в InsuranceCompany. Это нормально иметь null полей, когда null что-то означает (например, наличие Street1, Street2 и Street3 в одной таблице — это нормально; Street2 и Street3 почти всегда будут нулевыми — вы бы не поместили их в другую таблицу, не так ли? ?).   -  person Cᴏʀʏ    schedule 27.05.2016
comment
В дополнение к превосходному мнению Кори. База данных должна быть разработана с использованием 3-й нормальной формы (tutorialspoint.com/sql/ Third- normal-form.htm). Ухаживать за ним будет намного проще. Добавление нового столбца не будет проблемой, потому что вы можете установить значение по умолчанию или разрешить NULL при добавлении столбца.   -  person Eric S    schedule 27.05.2016
comment
Я согласен на 10000% с @Cᴏʀʏ. Хотя я бы добавил пару вещей. У вас есть 10 символов для номера телефона, но вы указываете, что вам необходимо иметь возможность поддерживать международные данные. Это не достаточно места. У вас также есть адрес электронной почты 50. Вам нужно сделать его НАМНОГО больше для некоторых адресов электронной почты. Реальная максимальная длина абсолютно нелепа, но вам, вероятно, нужно не менее 100 символов. Если вы придерживаетесь этого сумасшедшего дизайна, вы, вероятно, также захотите включить уникальный индекс почти для каждой таблицы с внешним ключом. Вы не можете разрешить такие вещи, как один адрес с несколькими кодами стран.   -  person Sean Lange    schedule 27.05.2016


Ответы (1)


Ладно вы, бездельники, говорите мне, что моя идея глупая.

Очевидно, вы правы. Спасибо @Cory, и @Eric S, и @Sean Lange.

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

Следуя вашему совету @Sean Lange, я увеличил длину поля электронной почты. Спасибо.

person ffrugone    schedule 17.06.2016