将“只读”对象作为序列化数据存储在关系数据库中

Question

我想知道将对象作为序列化数据（例如 json）存储在关系数据库中是否是一种好习惯。我知道这通常是一件坏事，而且我不打算广泛使用它，但我偶然发现了一个让我思考的案例。

所以，这是我的情况。我基本上是在构建一个移动订购系统，用于将物品从 A 点运送到 B 点。A 是起始地址，B 是目的地......两者都是用户的当前 GPS 坐标（以及街道名称、街道号码等可读数据） .

这些是要求：

• 每个订单都有一个起始地址
• 目标地址是可选的
• 一旦创建订单和地址，地址将永远不会更新
• 每个订单都会存储一组新的地址，这意味着如果有更多来自同一地址的订单，之前保存的地址将不会被重复使用
• 我不需要对地址数据进行任何查询，例如过滤、排序...
• 地址数据的结构（如果已修复）。我知道这就是序列化的优势所在，但我肯定不需要它。

那么，难题是是使用单独的表格存储地址数据（列：id、街道、街道编号、lat、lng...），还是简单地将地址存储为 JSON 字符串？

我看到，JSON 的唯一缺点是数据必须被序列化/反序列化。由于它只有几个字段，因此不会有太大的不同。

另一方面，我不喜欢单独的表格：

• 它可能有数百万行仅用于显示目的
• 如果所有内容都在一个表中，则更容易监控数据
• 无论在何处显示有关订单的信息，都需要数据，所以我需要一直加入这两个表
• 极不可能，但理论上，我可能会用完自动递增的 ID

我想我用标准的关系方法并将地址存储在单独的表中不会出错，但我看不出它有什么真正的优势。

Answer 1

您确定永远不需要对地址数据进行任何查询/分析吗？

如果这是一个小的个人项目，这似乎很好。

但是，如果您需要更改任何属性，特别是如果这个项目不是完全由您决定的，那将是一个巨大的麻烦。我不会太担心“数百万行仅用于显示目的”——现代数据库系统已针对存储大量行进行了优化，但不一定是非结构化数据。

因此，我强烈建议您采用久经考验的关系方法。

• 它可能有数百万行仅用于显示目的：如果您担心自动递增的 ID 用完，我敢打赌，您想进行大规模交付服务。您真的不想按 GPS 坐标进行分组吗？

• 如果所有内容都在一个表中，则更容易监控数据：我认为这不是真的。显然，如果所有数据都以一致的格式存储，就会出现这种情况。但是，监控包含您每次都必须处理的 JSON 数据似乎是另一回事。

• 显示订单信息的任何地方都需要数据，所以我需要一直加入这两个表：如果这实际上更慢，公平点。但是，如果你只加入你关心的子表，我想加入会比 json 解析运行得更快。

• 极不可能，但理论上，我可能会用完自动递增的 ID：请参阅 this question。不会发生的。

Answer 2

我会选择关系选项，原因如下：

1. 我对数据规范化很感兴趣

2. 如果您的 json 地址模式发生变化，您不必重新处理所有字符串。您只需在表格中添加或删除一个字段，然后调整您的 crud。