使用主键更新SQL Server中的外部表

Question

标题可能有点误导，因为我真的不知道该怎么称呼它。 Here是我的dbml，我使用存储库模式在我的应用程序层和我的SQL层之间进行通信。正如你所看到的，我有四张桌子。其中三人有一个外键给ContactId。我使用这种方法，因为我需要存储一个“数组”，所以我做了几个表。所以现在我想知道如何制作，以便我可以将电子邮件地址，电话号码或地址“添加”到联系人，并通过联系人进行操作。

Answer 1

“明显”的答案是有一个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

无论哪种方式，每行存储一个电子邮件地址。这应该会使添加或删除单个电子邮件变得更加容易，并且会消除当前设计中三个电子邮件的限制。它还使添加有关每个电子邮件地址的附加信息变得更加容易。例如，它是一个家庭或工作地址。或者，该电子邮件地址是否有效。

Answer 2

如果你想要一个完全规范化的设计，那么你应该有类似

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（最大）备注列。如果是这样的话，那么你就可以进行非规范化设计了一下：

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。管理无限数量的电子邮件地址，电话号码和地址更加灵活，但在用户界面中添加了更多工作。大多数联系人捕获设计并不需要捕获给定联系人的数十个电子邮件地址，因此完全标准化的设计只需添加比必要的更多的工作。