将 JSON 存储在 sqlite 字段中？
我正在编写一个与 Web API 通信的应用程序，该 API 使用 JSON 进行响应。目前，我正在使用 gson 将 JSON 对象转换为 Java 对象（这很棒， 顺便一提）。
现在，我想将其中一些对象存储在 SQLite 数据库中。但是，它们有很多永远不会在查询中使用的属性（即我不会使用这些属性进行 ORDER、WHERE 或类似操作），所以我觉得没有必要为所有这些创建列。我正在考虑做的是：
- 仅包含查询数据库时将使用的基本数据的列
- 有一个
TEXT或BLOB列（您推荐哪一个） ？），它存储实际的 JSON，因此我可以从中重新创建我的 Java 对象并访问所有数据。
这既能让我的生活更轻松，又能简化我的代码（在处理来自 API 的数据和处理来自数据库的数据时，我不必编写非常不同的代码）。
然而，虽然我没有看到任何缺点，但感觉有点可疑。
如果我使用这种技术，你认为我会遇到什么样的麻烦？
I'm writing an application that communicates with a web API, which responds with JSON. Currently, I'm translating the JSON objects to Java objects using gson (which is awesome, by the way).
Now, I want to store some of these objects in an SQLite database. However, they have lots of properties that would never be used in queries (i.e. I won't be ORDERing, WHEREing, or anything like that with those properties), so I feel it's unnecessary to create columns for all of them. What I'm thinking of doing is:
- Only have columns for the essential data that will be used when querying the database
- Have one
TEXTorBLOBcolumn (which one do you recommend?) that stores the actual JSON, so I can recreate my Java object from it and access all the data.
This would both make my life easier and streamline my code (I would not have to write very different code when dealing with data from the API vs. data from the database).
However, although I see no downsides, it feels a bit fishy.
What kind of trouble do you think I would run into if I use this technique?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不喜欢的主要一点是它依赖于存储/检索的 JSON 的结构才有效，因为它完全不受数据库控制。并不是说您无法针对可能出现的问题采取预防措施，但如果 JSON 被某种方式截断或以其他方式受到损害，导致解析器出错，那么您就会丢失整个对象，而不仅仅是一个无效或被截断的属性。如果这是一个可以接受的风险，那么这可能是一种合理的技术。
The main thing I wouldn't like about it is relying on the structure of the stored/retrieved JSON to be valid, since it's completely out of the hands of the database. Not that you can't take precautions against possible issues, but if the JSON is somehow truncated or otherwise compromised in a way that trips up the parser, you're then missing the entire object instead of just one invalid or truncated property. If that's an acceptable risk, then it's probably a reasonable technique.