mysql - 将 "readonly"对象作为序列化数据存储在关系数据库中

Question

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

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

这些是要求:

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

因此，难题在于是为地址数据使用单独的表(列:id、街道、街道号码、纬度、经度...)，还是简单地将地址存储为 JSON 字符串？

据我所知，JSON 的唯一缺点是必须对数据进行序列化/反序列化。由于它只有几个字段，因此不会产生太大影响。

另一方面，有一些我不喜欢单独表格的地方:

• 它可能有数百万行，仅用于显示目的
• 如果所有内容都在一张表中，则更容易监控数据
• 在显示有关订单的信息的任何地方都需要数据，因此我需要一直连接这 2 个表
• 极不可能，但从理论上讲，我可能会用完自动递增的 ID

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

Answer 1

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

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

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

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

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

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

• 在显示有关订单的信息的任何地方都需要数据，因此我需要始终连接这 2 个表:如果这实际上更慢，公平点。但是，如果您只连接您关心的子表，我想连接会比 json 解析运行得更快。

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