How to use mysql json easy to develop?
Such as the title, and use json data types in addition to outside business because without frequent change table structure changes and updates json part, what advantages it? What's odd kinky skills?
programmer
Never actually used, the brain make their own pros and cons, start with the advantages:
1, it seems very consistent with the trend ah (in fact this point there is nothing eggs with ......)
2, not because of changes in demand and change table structure, this needs to change a little early in the project every day, 3 Tianyi when major changes are useful for quick out function, on-line publishing is also convenient
3, in some scenarios and interaction become more convenient front end
4, the development of fast, there is no need to write SQL a field a field is inserted, with a minimum of circumstances as long as the two fields: id primary key, a json field, ah, should be able to be faster than writing 10 field a little, not to mention The actual service is often much more than 10 fields
Then the brain make some drawbacks:
1, almost no database portability, ah have wood there? Of course, if you're bent on hanging in a tree MySQL when I did not say
2, the query efficiency should be a ratio of a field, however, especially when the amount of data up (this is totally self-brain supplement, there is no data, information support) [] query performance is very slow
3, the code somewhat more demanding, because when a field in a database table structure may also be used as the last line of defense dirty data, then this line of defense into json gone to give entirely by the code logic do check the correctness of data
[Higher] code requires
From version began 5.7, Mysql support json up.
I practice, the input and output of stored procedures, are used to solve json. In particular stored procedure can return multiple rows, this can only be solved with Json.
such as
create function myfunc(p json) returns json
1, the previous version 5.7 function, is unable to return multiple rows of data through json, the perfect solution; return to the past is to rely on a number of parameters to define multiple out parameters achieved in the procedure, and now also by elegant function returns json in miles instead.
2, the incoming parameters p, using the json greatly increased flexibility. For example, we want to add a parameter, in the past had to modify the definition of myfunc, and 11 changes in the call at all. And now after using the json, the parameter list myfunc not changed, call the office on (probably) do not move.
Xie invited
json as a carrying structure such that the structure of the text information may be decoupled from the database.
This sentence is a little convoluted, we slowly explained.
First, do not use when json, if we want to design a User object. The information table is as follows:
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `email` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) );
Then we designed this system configuration information such User is passed:
· Presentation layer ( HTML / CSS / anjular / reace / VUE ......): Display individual properties objects according to user needs
· Model layer ( the Java / PHP / c ++ / Pyhton ......): processing user object
· DAO layer (Mybatis / Hibernate ......): complete object-relational mapping
· Persistence Layer (MySql / SqlServer ......): each field store
So we can see that in this system, the structural information from the User object persistence layer to the presentation layer is completely through and consistent. This has the advantage to improve the consistency, making the code easier to read. But there is one important question: coupling is too high, the expansion is not unfriendly.
假设我们要增加给User对象增加一个属性age。那我们各个层都要进行修改，例如数据库层结构需要修改为：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `email` varchar(255) DEFAULT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`) );
同时，其他各层都要进行修改。
而引入json进行存储之后。假设我们将主要信息字段id、name字段进行保留，而次要信息字段转为json。则数据表中的信息变为：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `detail` json(255) DEFAULT NULL, PRIMARY KEY (`id`) );
对于已经放入detail中的次要信息而言，User的结构信息是这样传递的：
· 表现层（html/css/anjular/reace/vue……）：根据需求展示用户对象各个属性
· 模型层（java/php/c++/pyhton……）：进行json结构与模型的映射
· DAO层（Mybatis/Hibernate……）:无需完成属性与字段的映射
· 持久层(MySql/SqlServer……):无需了解字段详情
这样，使得User的次要结构信息可以与数据库解耦。当User中再增加一个属性age时，我们只需要在模型层增加一个age属性，甚至连序列化操作都不需要变动就可以直接在表现层进行使用。
NoSql数据库中的文档数据库便多用json进行数据存储，来实现与对象结构的解耦。而Mysql中使用json类型，其实是向这种方式的一种靠拢。我们可以：
· 将经常查询的属性采用独立字段
· 将不经常查询且变动频繁的字段存入json中
从而实现运行效率和可扩展性之间的平衡。
用json代替数据库的字段来实现“解耦”是非常可疑的。
数据库之上，愿意用json在层之间传递是程序员自己的事；
而在数据库里，把age存到json里，看不到任何好处。比如按照age排序咋实现？
所以，在设计时要将这样的字段独立出来。而将一些经常变动，但是又不会独立查询的字段放到json中。
偶尔查询比较复杂，只能用“like”语句了。所以里边还是尽量放不经常查询的字段。
举个例子，备注信息就可以放在里边，而且对于不同的人，备注信息是不同的，有的人备注的是家庭住址，有的人备注的是毕业学校，有的人备注的是常用联系人。。。有的人备注的是前面的一项或者多项。所以这里边的字段很少是作为查询条件出现的。
postgresql json可作为查询条件
是的，听说pq很强而且纯开源
如果只是存储，那和text类型没什么区别。关键是要支持json函数操作。
推荐个我自己的免费视频：
MySQL 8.0新特性
http://www.imooc.com/learn/1102
使用Json是把校验字段类型的工作移动到了应用，嗯，反而增加了工作量。
还是不建议直接用mysql存储JSON，主要是出于扩展性的考虑
最大的好处就是master-detail数据可以一次查询出来，既不需要join，也不需要分两次查询。
json也是key—value结构。只不过是用{}和，分隔的key和value。mysql是以表格储存数据单位的。
以表格储存数据，一个key可以对应多个value，就是为了避免key值重复问题，减少数据重复。
mongodb是完全用key—value储存的，但和json有一些不同。如果你想用内存关系型数据库，mongodb不一定是好的选择，只不过mongodb提供了很多http接口和rpc接口，实现了分布式数据储存。
mysql用key—value储存，还比不过mongodb。
主要是mysql的ACID上完备有众多库支持，mongodb的4.0版本才支持，不想要引入新东西
别把NoSQL的思想用在RDBMS上
你会后悔的
我们一般在mysql之外做json封装给前端，没必要底层就开始封json对象，各自有专攻。