我想知道将对象作为序列化数据（例如json）存储在关系数据库中是否是一种好习惯。我知道这通常是一件坏事，我并没有计划广泛使用它，但我偶然发现了一个让我思考的案例。
所以，这是我的情况。我基本上建立了一个移动订购系统，用于从A点到B点交付物品.A是起始地址，B是目的地......两者都是用户的当前GPS坐标（以及街道名称，街道号码等可读数据）
这些是要求：
因此，困境在于是否为地址数据使用单独的表（列：id，街道，街道号，纬度，等等...），或者只是将地址存储为JSON字符串？
我看到，唯一有JSON的缺点是数据必须被序列化/反序列化。由于它只有几个字段，因此无法产生太大的影响。
另一方面，有一些我不喜欢的东西与单独的表：
我想我的标准关系方法和存储地址在一个单独的表中不会出错，但我只是看不到任何真正的优势。
答案 0 :(得分：2)
我会选择关系选项，原因如下：
我对数据规范化很虔诚
如果您的json地址模式发生更改，则无需重新处理所有字符串。您只需在表格中添加或删除一个字段，然后调整您的评论。
答案 1 :(得分：2)
您是否确定永远不需要对地址数据进行任何查询/分析？
如果这是一个小小的个人项目，这似乎很好。
但是，如果你需要更改任何属性，特别是如果这个项目没有完全由你决定，那将是一个巨大的麻烦。我不会太担心“数百万行仅用于显示目的” - 现代数据库系统针对存储大量行进行了优化，但不一定是非结构化数据。
所以，我强烈建议你采用经过验证的关系方法。
它可能有数百万行仅用于显示目的：如果您担心自动增加的ID用完了，我打赌你想要做一些大规模的交付服务。你真的不想按GPS坐标分组吗？
如果所有内容都在一个表格中，则监控数据会更容易：我不认为这是真的。显然，如果所有数据都以一致的格式存储，情况就是如此。但是，监控每次都必须处理的JSON数据似乎是另一个故事。
只要显示有关订单的信息，就需要数据，因此我需要一直加入这两个表：如果这实际上更慢，公平点。但是，如果你只加入你所关心的子表，我想联接将比json解析运行得更快。
极不可能，但从理论上讲，我可能会用完自动递增的ID ：请参阅this question。不会发生。