Внешние таблицы в SQL Server обновлены с помощью первичного ключа - PullRequest
Новая
       21

Внешние таблицы в SQL Server обновлены с помощью первичного ключа

0 голосов
/ 20 февраля 2010

Название может вводить в заблуждение, потому что я не знал, как его назвать. Здесь - это мой dbml, и я использую шаблон репозитория для связи между уровнем приложения и уровнем SQL. Как видите, у меня есть четыре таблицы. Три из них имеют внешний ключ для ContactId. Я использовал этот метод, потому что мне нужно хранить «массив», поэтому я сделал несколько таблиц. Поэтому теперь мне интересно, как сделать так, чтобы я мог «добавить» адрес электронной почты, номер телефона или адрес для контакта и манипулировать им через контакт.

Ответы [ 2 ]

2 голосов
/ 20 февраля 2010

«Очевидный» ответ - иметь класс Contact, который имеет методы addEmail, addPhone и addAddress, а также соответствующие хранимые процедуры в базе данных. Есть ли еще что-то в твоем вопросе?

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

EmailId (int - PK)
ContactId  (int - FK to Contact)
EmailAddress (varchar)

ИЛИ может быть: 

ContactId  (int - FK)
EmailNumber (tinyint? sequential 1, 2, 3, ...)
EmailAddress (varchar)

с PK: ContactId и EmailNumber

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

0 голосов
/ 20 февраля 2010

Если вы хотели полностью нормализованный дизайн, тогда у вас должно быть что-то вроде 

Create Table dbo.Contacts
(
    Id int not null Primary Key Clustered
    , FirstName nvarchar(25) null 
    ...
)

Create Table dbo.ContactAddresses
(
    Id int not null Primary Key Clustered
    , ContactId int not null
    , Street nvarchar(max) null
    , City nvarchar(40) null
    ...
    , Constraint FK_ContactAddresses_Contacts
        Foreign Key ( ContactId )
        References dbo.Contacts( Id )
)

Create Table dbo.ContactEmail
(
    Id int not null Primary Key Clustered
    , ContactId int not null
    , Type nvarchar(10) not null
    , Address nvarchar(255) not null
    ...
    , Constraint CK_ContactEmail_Type Check Type In('Primary','Secondary',...)
    , Constraint UK_ContactEmail_Address Unique ( ContactId, Type, Address )
    , Constraint FK_ContactEmail_Contacts
        Foreign Key ( ContactId )
        References dbo.Contacts( Id )
)

Create Table dbo.ContactPhone
(
    Id int not null Primary Key Clustered
    , ContactId int not null
    , Type nvarchar(10) not null
    , Number varchar(20) not null
    ...
    , Constraint UK_ContactPhone Unique ( ContactId, Type, Number )
    , Constraint CK_ContactPhone_Type Check Type In('Office','Fax','Home',...'Mobile')
    , Constraint FK_ContactPhone_Contacts
        Foreign Key ( ContactId )
        References dbo.Contacts( Id )
)

Если вы хотите более контролируемый список типов электронной почты или телефонов, вы можете добавить родительскую таблицу и внешний ключ для их хранения. Чего не хватает в этом дизайне, так это защиты от адресации. Требуется ли пользователю вводить полный адрес? Этот дизайн позволяет неограниченное количество электронных писем, телефонных номеров и адресов. Однако это может быть излишним для того, что вам нужно.

Если вы разрабатываете полнофункциональный менеджер контактов для замены чего-то вроде Outlook, тогда вышеприведенный дизайн будет правильным решением. Тем не менее, большинство систем, которые собирают некоторые контактные данные, не предназначены для полного управления контактами. Если это так, то вам следует указать разумные ограничения на объем данных, которые вы будете собирать. Например, вы действительно собираетесь разрешить пользователям вводить восемь телефонных номеров для одного контакта? Вероятно, более реалистично, что 99% контактов будут иметь только два или три телефонных номера. Включите в контакт столбец nvarchar (max) Note для людей, которые хотят захватить сотни телефонных номеров и адресов электронной почты. Если это так, то вы можете немного денормализовать свой дизайн: 

Create Table dbo.Contacts
(
    Id int not null Primary Key Clustered
    , FirstName nvarchar(25) null 
    ...
    , PrimaryEmailAddress nvarchar(255) null
    , SecondaryEmailAddress nvarchar(255) null
    , OfficePhone nvarchar(25) null
    , MobilePhone nvarchar(25) null
    , FaxPhone nvarchar(25) null
    , Note nvarchar(max) null
    ...
    , Constraint UK_Contacts Unique ( FirstName.... )
)

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

Гибкость связана 1: 1 со сложностью. Управление неограниченным количеством адресов электронной почты, телефонных номеров и адресов является более гибким, но добавляет больше работы в пользовательском интерфейсе. Большинство проектов захвата контактов на самом деле не нужно собирать десятки адресов электронной почты для данного контакта, и, следовательно, полностью нормализованный дизайн просто добавляет больше работы, чем необходимо.

...