数据库JSON字段设计思路

任务的阶段信息直接存储为JSON格式,这种格式避免了表关联,避免建表,应用层处理也简单的多了。

1. JSON内容为信息性质,而不具备非统计功能;简单讲就是展示,不能用于深度处理;

2. JSON内容不应该是多表需要的;比如一些信息其实是被多表共享的,这就不可以了,因为存在一个更新批量的问题;JSON内容一旦修改/创建其实是要影响多个表,那么慎用JSON;

3. JSON内容应该是依附性比较强,比如阶段信息永远都是依附于任务而存在,如果有逻辑要单独针对“阶段”内容进行处理,或者在表的概念上有需要以“阶段表”做主表的情况下,JSON化慎用,最好是单独处理为一张表。

4. JSON中的字段作为检索条件的慎用,尽管MySql以及MongoDB都支持对于JSON的使用,但是如果数据库服务器还要对JSON进行解析再处理无疑在效率上是有问题的。

时间: 2024-10-17 03:42:47

数据库JSON字段设计思路的相关文章

数据库的字段设计的几个心得

数据库的字段设计有很多细节性的技巧,下面将过去在开发中体会到经验整理出来,做个备忘. tinyint 是-128到128 .当属性设置为unsigned的时候.最大值就是255了.现在知道为什么需要设置为unsigned属性了.原来是为了最大限度的使用给予的存储空间.如果不设置.那么假如你的值都是正数的.那么-128这一百多个数字就相当于是浪费了.澳门葡京赌场是真的吗 tinyint会自动设置为tinyint(3). smallint 不设置unsigned的时候,也有3万多的样子. tinyt

关于数据库‘状态’字段设计的思考与实践

最近在做订单及支付相关的系统,在订单表的设计阶段,团队成员就‘订单状态’数据库字段设计有了一些分歧,网上也有不少关于这方面的思考和探讨,结合这些资料和项目的实际情况,拟对一些共性问题进行更深一层的思考,笔耕在此,和大家一起探讨. 问题综述 这里的分歧点即有团队内部的分歧点,也有网络上常见的一些分歧点,先将存在的分歧点抛出来: 1.订单表的‘订单状态’字段对应的字典值应当包含哪些状态值?对于‘已评论’.‘已退货’.’已退款’这类状态是放到‘订单状态’中?还是独立一个字段标识? 2.订单表的‘订单状

关于数据库“状态”字段设计的思考与实践

目录 1. 问题综述 2. 业务分析 3. 问题一.订单表的'订单状态'字段应当包含哪些状态值? 4. 问题二.订单表的'订单状态'字段的字典值的表示形式? 5. 问题三.数据库表的'状态'字段使用何种类型 6. 问题结论汇总 7. 参考资料 正文 最近在做订单及支付相关的系统,在订单表的设计阶段,团队成员就"订单状态"数据库字段设计有了一些分歧,网上也有不少关于这方面的思考和探讨,结合这些资料和项目的实际情况,拟对一些共性问题进行更深一层的思考,笔耕在此,和大家一起探讨. 1. 问题

关系型数据库设计表和字段的思路

做数据库的设计一定要有思路,把各个表的依赖关系整理清楚.我们就讲一个小例子就可以让你轻松掌握到设计数据表和字段的思路 创建表和字段之前首先要明确各表之间的依赖关系场景: 比如现在要做一个电商网站的数据库整理清楚要设计的表:用户信息表,商品信息表,结算的表.PS:购物车的表请根据此例举一反三的去思考它的依赖关系,吴小迪相信聪明的您一定会做出来的思路:我们要 先设置不需要依赖其他表的表的字段(这句话一定要看懂,看不懂再来几遍,看懂为止),比如说用户信息和商品信息的表就 不需要依赖 其他的表,那么我们

数据库水平切分的原理探讨、设计思路--数据库分库,分表,集群,负载均衡器

本文转载:http://www.cnblogs.com/olartan/archive/2009/12/02/1615131.html 第1章  引言 数据量巨大时,首先把多表分算到不同的DB中,然后把数据根据关键列,分布到不同的数据库中.库分布以后,系统的查询,io等操作都可以有多个机器组成的群组共同完成了.本文主要就是针对,海量数据库,进行分库.分表.负载均衡原理,进行探讨,并提出解决方案. 随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题.对于一个大型的互联网应用,每

数据库架构设计思路

一 .58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证"读"高可用的方法:复制从库,冗余数据,如下图  带来的问题:主从不一致 解决方案:见下文 保证"写"高可用的一般方法:双主模式,即复制主库(很多公司用单master,此时无法保证写的可用性),冗余数据,如下图  带来的问题:双主同步key冲突,引不一致 解决方案: a)方案一:由数据库或者业务层保证key在两个主上不冲突 b)方案二:见下文 58同

互联网数据库架构设计思路

一 .58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证"读"高可用的方法:复制从库,冗余数据,如下图   带来的问题:主从不一致 解决方案:见下文 保证"写"高可用的一般方法:双主模式,即复制主库(很多公司用单master,此时无法保证写的可用性),冗余数据,如下图   带来的问题:双主同步key冲突,引不一致 解决方案: a)方案一:由数据库或者业务层保证key在两个主上不冲突 b)方案二:见下文 5

用MongoDB数据库来管理办公系统中文档型的表单和信息——通用流程化应用审批单设计思路(二,续)

1.办公系统中文档的定义 办公系统中的文档就是指对数据不敏感的业务,例如流程中的审批单.信息专栏.数据上报.信息记录等.而对于这些信息的管理,特别是时效性较强的管理记录,仍采用关系型数据库进行管理. (1)流程中审批单 流程中审批单由功能按钮区.特殊功能区.业务表单区.附件区.审批意见区等区域构成,其中,业务表单区理论上包含附件和意见,但是由于附件和意见的业务特殊性,需要单独进行管理,剩下的业务表单就可以看作文档了. 在一些流程审批业务中,业务信息有的是以Excel或word文件等方式专递,这样

mysql数据库中,如何对json数据类型的值进行修改?通过json_set函数对json字段值进行修改?

需求描述: 今天在看mysql中存放json数据类型的问题,对于json数据进行修改的操作, 在此记录下. 操作过程: 1.创建包含json数据类型的表,插入基础数据 mysql> create table tab_json(id int not null auto_increment primary key,data json); Query OK, 0 rows affected (0.03 sec) mysql> insert into tab_json values (null,'{&