2

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

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

这些是要求：

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

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

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

另一方面，有几件事我不喜欢单独的表格：

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

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

4

2 回答 2

2

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

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

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

于 2013-11-14T01:33:31.747 回答
2

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

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

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

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

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

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

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

  • 极不可能，但从理论上讲，我可能会用完自动递增的 id：请参阅此问题。不会发生。

于 2013-11-14T01:42:02.613 回答