我正在尝试为一家豪华轿车公司建立一个数据库，我不知道应该为与客户，司机，关联公司和订单相关的地址做多少规范化。
基本上会员和司机地址如下所示： address_line_1，address_line_2，city，state，zipcode，country
我的问题来自订单和客户地址。 他们应该是这样的： address_line_1，address_line_2，city，state，zipcode，country，address_type_1（home，business），address_type_2（提货，送货 - 这只需要包含在订单中）。
因此，在所有四个表之间，我在地址字段中有相似之处，但客户和订单表中的两个字段不同。
我需要提一下，每条记录都会被标识为唯一ID。 例如：
客户ID - 10,000 - 99,999
订单ID - 100,000 - 无限制
驱动程序ID - a1 - a999（可能）
会员ID - 1,000 - 9,999
这些只是示例，所以不要花费太多时间来理解它们。
我应该使用多少个地址表来创建一个良好的规范化数据库？
在这一刻，我脑子里有三个想法：
包含所有字段的一个地址表以及描述地址类型（客户，订单，关联企业，驱动程序）的额外字段。不太喜欢这个。
两个地址表。一个是司机和附属机构，另一个是客户和订单。对于第二个表，我将为客户提供永远为NULL的字段。不喜欢这个。
三个地址表。一个用于司机和附属机构，一个用于客户，一个用于订单。没有未使用的字段让我认为这可能是比其他两个更好的选择。
有没有人对这三个选项提出建议，或者甚至是更好的选择？
非常感谢。
更新：
不要打扰表ID的编号系统。那只是一个例子。我仍然没有时间找出最好的编号系统。一旦我解决了我的地址问题就会达到目的。
根据Matt的回答，我很想将驱动程序和联盟表留下包含的地址，并以某种方式对客户和订单表进行整理。
对于客户，我肯定需要一个地址表，因为客户可以拥有多个地址（家庭，商业1，商业2，最喜欢的地方等），我希望这些地址存储在他们的个人资料中以便于访问。
我忘记提及订单表的某些内容，这可能会改变问题的等式。 对于任何订单，我需要有一个PICK-UP和DROP-OFF位置。但这可以是地址（街道地址）或机场。这意味着与街道地址相关的字段与机场特定字段不匹配。所以我很确定在一个表格中有四个实体（pu_address，pu_airpot，do_address，do_airport）（所有这些都有它们的特定字段）会让我留在未使用的空间并且编程混乱。 例如： 接送字段：Address_type，Address_line_1，...，州，国家，机场，航空公司，Flt no，... 和接送一样的东西。
所以我仍然对Order表有一个问题，我不确定如何继续前进。无论是否使用额外的桌子，我都需要包括地址和机场接送地点。
更新 再次感谢马特。首先，是的，我将地址存储在单独的字段中。订单仍然存在问题。我将举例说明什么类型的pu和豪华轿车服务使用。地址：123 Main St，Chicago，Il，60640;机场：ORD，AA，123。我需要将所有这些领域整合到表中。
选项： 订单表
order_id，...，需要同时包含机场和地址字段的接送字段，包含机场和地址字段的下拉字段。
此选项仍然听起来不对。
接下来将有两个额外的表。一个是地址（包括用于识别提货或下车的领域）。另一个是机场（有pu的场地或者也可以）。
我也不喜欢这个选项，因为我需要做两个查询才能检索订单记录的信息。首先，我将检索订单信息，在我知道接送和下车（机场或地址）的类型后，我会再进行一次查询以检索特定的上下车信息。
所以，再说一遍......我做错了什么？我想念一下吗？
是的，我肯定会使用一些验证系统来确保地址是正确的。
答案 0 :(得分：4)
现在可能已经太晚了，但我会建议1 Addresses表（address_id，address_line_1，address_line_2，city，state ，zipcode，country，address_type（FK到AddressTypes表）），因为这将遵循标准规范化规则。您的Orders表格与Addresses表格有两个外键关系 - pickup_address_id和delivery_address_id。我对Customers，Drivers和Affiliates表的设计有疑问，但如果没有更好地理解它们之间的关系，则难以规定解决方案。
一个选项（但我不知道它是否适合你）将是一个Parties表（party_id，party_type），它创建一个超类型/子类型关系（每种情况下为一对一或零）与Customers，Drivers和Affiliates，所有这些都是Party的类型。我建议阅读David C. Hay关于数据建模的一两篇文章，以便更好地理解。
答案 1 :(得分：3)
我实际上使用SmartyStreets在地址验证行业工作，其中处理和存储地址是我们的专业领域。根据我的经验，我看到过很多与你很相似的情况。
我最初关注的是基于记录类型的细分ID号。如果四种类型的记录（客户，驱动程序，关联公司，订单）存储在不同的表中，为什么需要ID范围限制？（更新：这不是手头的主要问题......）
现在，关于数据库设计。理想情况下，您的设计应该反映核心域的操作（即协调客户，订单，驱动程序等），而不仅仅是地址数据。虽然地址可能很重要，但它们并非您企业的核心业务。在此基础上以及我从原始帖子中收集到的内容，我会立即犹豫地将地址与实际记录分开存储。
虽然每个表中都有类似的字段，但它们代表了不同的业务目的，并且您不会冒未使用的不必要字段的风险。所以问题不在于“如何我做了很多地址表，“这更像是一个甚至只为地址制作任何表的问题。
虽然地址有多种形式和形式，但对于豪华轿车公司来说，拥有正确的地址信息以及对数据库进行规范化非常重要。 USPS（我假设您是美国的）证明某些供应商提供地址规范化服务。这称为CASS™认证。通过CASS™服务运行每个地址，您就完成了。地址看起来一样，有完整的信息，也可以交付。我建议您使用LiveAddress开始搜索，这将在入境点验证地址，或CASS list scrubbing service，这将立即验证一批地址（并警告您重复）
更新：如果客户可能有多个地址，那么是的，我会提倡使用单独的表格。但是，您仍然希望使用CASS标准化/验证它们，因此如果需要，您可以稍后提取重复项（此外，您将知道实际存在的地址）。
因此，除此之外，考虑将每个地址与其关联的实际记录（不在单独的表中）内联存储。
如需进一步的问题或指示，我可亲自协助。
<强>更新
关于从机场分离地址：根据您的业务需求，这可能是有效的区别，但请记住，机场也有地址。您可以在表格中添加一个字段，以存储公司名称或地址所指的位置，例如“奥黑尔国际机场”。这可以巩固一些领域。另外，我建议您按地址（街道，城市，州，邮政等）将地址存储在不同的字段中。