Question

我有一个'策略'问题。

事情是，我们有一张客户地址和客户订单表。结构就像（只是一个例子，忽略归档类型等）：

Address
id INT
line1 TEXT
line2 TEXT
state TEXT
zip TEXT
countryid INT

为了保持数据的历史有效性，我们将这些地址存储在带有订单的文本字段中（以前是通过引用完成的，但这是错误的，因为如果地址更改所有旧订单也会更改传递地址，这是错误的）。 E.g：

Orders
id INT
productid INT
quantity INT
delivery_address TEXT

delivery address类似于CONCAT_WS("\n",line1,line2,state,zip,country_name)

一切都很好，但是看起来客户需要访问历史数据并能够以XML格式导出这些数据并且他们希望再次正确地拆分这些行。因为有时没有line2或state或zip或者其他什么，我们如何以一种我们可以破译每行的“标签”的方式存储这些信息呢？

建议存储为JSON编码数组，但这是最好的方法吗？我想过将它存储为XML ...或者可能创建那些6-10个额外的列并存储每个订单的地址数据？也许你们中的一些人在处理这类事情方面有更多的经验，并且能够指出我正确的方向。

提前致谢！

Answer 1

就个人而言，我会将地址建模为单个表，每次更新地址都会生成一个新行，这将被标记为当前地址。

我猜你可以在没有相关订单的情况下允许删除，但是将旧记录标记为非活动状态会更简单。

这将允许您保留订单之间的关系＆amp;地址，并在以后轻松查询历史数据。

查看slowly changing dimensions

的维基百科条目

Answer 2

恕我直言的最佳方式是将历史记录添加到地址表中。这将导致为其键添加额外的元素（例如address_id和{start_of_validity，end_of_validity}）客户ID不会成为customer表中的外键。 orders表仅引用address_id字段（时间上“稳定”）。新订单将引用地址中的“当前”行。

注意：我不认识json。

Answer 3

您应该将这些字段存储为6-10个额外字段，就像您在当前地址中一样。你知道，这样你就可以得到所有信息，而不必解析任何东西。

任何其他方法（连接，JSON，XML）将使您在需要访问信息时必须进行解析。

Answer 4

当你说“以前它是通过引用完成的，但是这是错误的，因为如果地址改变了所有旧订单也改变了递送地址，这是错误的”，那就没那么错了......

好笑，不是吗？

因此，正如其他人所建议的那样，地址应该（必须？）存储在一个独立的表中。然后，您将拥有不同的地址类型（发票，交付），地址状态（活动，非活动）和事实上的地址历史记录日志......

Answer 5

为了能够将地址数据用于将来的使用，您肯定希望保留尽可能多的元数据（意思是地址，城市，州和ZIP等字段）。通过将所有数据全部拉成一行来丢失这些数据看起来更简单，并且可以节省少量空间，但最终并不是最好的方法。实际上，将它拆开是非常困难的 - 就像从一般的，一刀切的“名称”列中分离出名字和姓氏一样。将数据存储在完整的条目中，利用6-10个新字段（如上所述）是最好的方法。

更好的方法是在首次输入时标准化地址（至少是美国地址）。这将确保地址真实可交付，并在未来消除运输问题。我的想法，始终保留尽可能多的数据，因为存储便宜且数据很有价值。

为了充分披露，我是创始人SmartyStreets。我们提供街道地址验证。

存储订单地址的最佳策略

5 个答案: