使用模块化地址时的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

---

谢谢。

好吧，你们这些废物，告诉我我的想法很愚蠢

显然，你是对的。谢谢你，科里，埃里克，还有肖恩·兰格

我将不同的表组合成一个“地址”表。在放弃之前，我尝试了存储过程、用户函数和视图的组合，但很明显，我只是想把一个方形的销钉塞进一个圆形的孔中

---

按照您的建议@Sean Lange，我扩展了电子邮件字段的长度。谢谢。

老实说，我不认为人们会意识到维持这种结构会有多么令人头痛。如果您想要一个地址表，请将其中与物理地址（街道、城市、州、国家、电话等）相关的所有列都放在其中。然后，像在保险公司一样使用外键。如果

null

意味着什么（例如，将Street1、Street2和Street3放在一个表中是可以的；Street2和Street3几乎总是空的——你不会将它们放在不同的表中，是吗？），这进一步说明了Cory的优点。应使用第三范式（）设计数据库。它将更容易维护。添加新列不是问题，因为您可以在添加列时设置默认值或允许

NULL

。我同意@C的10000%ᴏʀʏ. 不过我想补充几点。您的电话号码有10个字符，但表示您需要能够支持国际数据。那地方不够。您的电子邮件地址也为50。对于某些电子邮件地址，您需要将其设置得更大。真正的最大长度绝对是荒谬的，但您可能至少需要100个字符。如果您坚持这种疯狂的设计，您可能还希望在几乎每个表上使用外键包含唯一的索引。你不能允许一个地址有多个国家代码。