地址的数据库规范化

Question

我正在试图为一家豪华轿车公司构建一个数据库，并且我应该为与客户，驱动程序，关联公司和订单相关的地址做多少标准化工作。

基本上加盟和驱动程序的地址是这样的： 地址行，address_line_2，市，州，邮编，国家

我的问题来自于订单和客户地址。 它们应该看起来像这样： address_line_1，address_line_2，城市，州，邮政编码，国家，地址类型__1（住宅，商业），地址类型_2（接送，送机 - 这只需要包括订单）。

因此，在所有四个表中，我在地址字段中有相似之处，除了两个在客户和订单表中不同的字段。

我需要提及的是每个记录都将用唯一的ID标识。 例子：

客户ID - 10,000 - 99,999

订单ID - 100,000 - 无限制

驱动程序ID - A1 - A999（也许）

联盟ID - 1000 - 9999

这些只是一个例子，所以不要花太多的时间来试图理解它们。

我应该使用多少个地址表创建一个好的规范化数据库？

在这一刻我在我的脑海三个想法：

1. 一个地址表中的所有字段包含加上一个额外的一个描述地址类型（客户，订单，会员，驱动程序）。不太喜欢这个。

2. 两地址表。一个与司机和分支机构，一个与客户和订单。对于第二个表格，我将拥有字段，对于客户而言，字段始终为NULL。不要太喜欢这个。

3. 三地址表。一个用于司机和分支机构，一个用于客户，另一个用于订单。没有未使用的领域让我认为这可能是比其他两个更好的选择。

有没有人有关于这三个选项的建议，或者甚至更好的选择？

非常感谢。

UPDATE：

还不理会这些表ID编号系统。那只是一个例子。我仍然没有时间弄清楚最好的编号系统。一旦我解决了我的地址问题，就会得到解决。

从马特的回答我很想离开司机和附属表与地址包括在内，只是在某种程度上解决客户和订单表。

对于客户，我肯定会需要一个地址表，因为客户可以有多个地址（家庭，business1，business2，最喜欢的地方等），我想存储在他们的个人资料，以方便访问。

我忘了提到一些关于订单表的问题，这可能会改变问题的方程式。 对于任何订单，我需要一个拾取和删除位置。但这可以是地址（街道地址）或机场。这意味着与街道地址相关的字段不能匹配机场特定字段。所以我非常肯定，在一个表内（全部都有它们特定的字段）有四个实体（pu_address，pu_airpot，do_address，do_airport）会让我留下未使用的空间和编程混乱。 例如： 为接机领域：Address_type，Address_line_1，...，州，国家，机场，航空公司，Flt号，... 和脱落相同的东西作为接机。

所以我仍然有一个订单表的问题，我不知道如何前进。我需要同时使用地址和机场接送地点，以便使用或不使用额外的表格。

UPDATE 再次感谢马特。首先，是的，我会将地址存储在不同的字段中。订单仍然存在问题。我将举一个例子，说明什么类型的PU，并且使用豪华轿车服务。地址：芝加哥市123 Main St，60640;机场：ORD，AA，123.我需要将所有这些字段以某种方式整合到表格中。

选项： Order表

ORDER_ID，...，这就需要有两个机场，并解决领域，既有机场和地址字段落客领域回升场。

此选项仍然听起来不正确。

下一步将有两个额外的表。一个是地址（包括用于识别接机或丢弃的字段）。另一个将用于机场（有一个领域为PU或做）。

我不喜欢这个选项，因为我需要做两个查询才能检索只有订单记录的信息。首先，我将检索订单信息，在知道接送类型（机场或地址）后，我会再进行一次查询以检索具体的接送信息。

所以，再次...我做错了什么？我想念什么？

是的，我一定会使用一些验证系统来确保地址是正确的。

Answer 1

我实际上在地址验证行业工作，地址验证行业有SmartyStreets，其中处理和存储地址是我们的专业领域。根据我的经验，我已经看到了很多与您的情况非常相似的情况。

我最初关注的是根据记录类型划分ID号。如果四种类型的记录（客户，司机，分支机构，订单）存储在不同的表中，为什么需要ID范围限制？ （更新：这不是真正的主要问题...）

现在，有点关于数据库设计。理想情况下，您的设计应该反映核心域（即协调客户，订单，驱动程序等）的操作，而不仅仅是地址数据。虽然地址可能很重要，但它们不是核心业务您的业务。在这个基础上，从我从原来的帖子中收集到的信息，我会立即犹豫将地址与实际记录分开存储。

尽管每个表格中都有类似的字段，但它们表示不同的业务目的，您不会冒用未使用的不必要字段的风险。所以问题不在于“我如何制作很多地址表”，这更多的是仅针对地址制作任何表的问题。

虽然地址有多种形式和形式，但对于豪华轿车公司来说，重要的是要有正确的地址信息，并使数据库正常化。 USPS（我假设你是美国的）认证某些供应商提供地址标准化服务。这被称为CASS ™认证。通过CASS ™服务运行每个地址，就完成了。地址看起来是一样的，有完整的信息，并且可以交付。我建议你从LiveAddress开始你的搜索，这将验证在入口点的地址，或者一个CASS list scrubbing service，它将一次验证一批地址（并警告你重复）。

更新：在客户可能有几个地址的情况下，那么是的，我会主张使用一个单独的表。但是，您仍然需要使用CASS对其进行标准化/验证，因此如果需要，您可以稍后提取重复项（再加上您将知道实际存在的地址）。

因此，除此之外，请考虑将每个地址与其关联的实际记录（不在单独的表格中）内联存储。

如需进一步的问题或指导，我可以亲自协助。

UPDATE

关于从机场分离地址：这可能取决于你的业务需求的有效区分，但要记住，机场有地址了。您可以在表格中添加一个字段以存储公司名称或地址指向的位置，例如“奥黑尔国际机场”。这可以巩固一些领域。此外，我建议您将地址按组件（街道，城市，州，邮编等）存储在不同的字段中。

Answer 2

它可能为时已晚了，但我会建议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的一两篇关于数据建模的文章，以便更好地理解。