Json 作为一种通用的数据格式,由于其结构灵活、可拓展等特点,在某些场景下我们也会直接将数据以 Json 格式存储到数据库中。
本文将探讨在开发中使用 JSON 存储数据的常见场景,并通过具体的实例帮助大家更好地理解其应用。
1. 半结构化数据
当数据的结构是不固定的、是会动态变化时,如果仍然用结构化的存储方式(即先设计好表结构,然后用单独的字段去依次存储数据),显然是不合适的;因为我们是无法预先定义好表结构的。
这时,将数据序列化为 Json 后存储就很合适,不需要担心数据结构会变化的问题。
动态结构数据,例如 用户的个性化设置、动态表单数据等。
举个例子:
假设我们有一个用户表user
,其中需要存储用户的个性化设置,例如主题颜色、通知偏好等。这些设置可能因用户而异,且未来可能会新增或修改设置项,即数据的结构是会动态变化的。
CREATE TABLE user (
id INT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(64),
settings JSON
);
settings
字段可以存储如下 JSON 数据:
{
"theme": "dark",
"notifications": {
"email": true,
"sms": false,
"push": true
}
}
通过这种方式,我们可以轻松地扩展用户的设置项,而无需修改表结构。
2. 简化复杂数据结构
当数据具有复杂的嵌套结构时,使用 JSON 可以避免设计过多的表结构。例如,存储嵌套的评论、树形结构的数据等。
举个例子:
假设我们有一个博客系统,需要存储文章的评论信息。评论可能包含子评论,形成树形结构。
CREATE TABLE article (
id INT PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(255),
content TEXT,
comments JSON
);
comments
字段可以存储如下JSON数据:
[
{
"id": 1,
"user": "Alice",
"content": "Great article!",
"replies": [
{
"id": 2,
"user": "Bob",
"content": "I agree!"
}
]
},
{
"id": 3,
"user": "Charlie",
"content": "Nice work!"
}
]
通过这种方式,我们可以轻松地存储复杂的评论结构,而无需设计多张表。
3.配置项数据
当系统需要管理大量动态配置参数(如后台开关、页面模板参数、业务规则阈值等)时,如果为每个配置创建独立字段去存储就很不合适,因为配置参数是会动态变化的。
使用 JSON 存储可以适应配置项的动态拓展需要,尤其适合多租户系统中不同租户的独立配置管理。
举个例子:
多租户系统中,针对每个租户的不同模块 做配置管理,配置数据以 JSON 格式存储。
CREATE TABLE `sys_config` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`tenant_id` VARCHAR(50) COMMENT '租户ID(可选)',
`module` VARCHAR(50) NOT NULL COMMENT '模块名(如order/payment)',
`config_data` JSON NOT NULL COMMENT '配置内容(JSON格式)',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
配置数据示例:
1)订单模块配置
{
"auto_cancel_time": 30, // 订单自动取消时间(分钟)
"max_quantity": 100, // 单次最大购买数量
"enable_refund": true // 是否开启退款功能
}
2)支付模块配置
{
"payment_methods": ["alipay", "wechat"],
"timeout": 600,
"retry_times": 3
}
4.兼容外部系统数据格式
当对接第三方 API 时,如果对于拿到的 JSON 数据,并不需要实时解析所有字段,仅需存储原始数据以供后续查询使用,我们可以用一个字段直接存储原始 JSON 数据。
总结
在项目中使用 JSON 存储数据可以带来许多便利,尤其是在处理半结构化数据、简化复杂数据结构等场景下。
然而,使用 JSON 也需要注意查询性能和数据一致性问题。在实际开发中,应根据具体业务需求权衡使用 JSON 的利弊,选择最适合的方案。
如果有帮助的话,可以点个赞支持一下嘛
🙏