对于前端来说,只要加一个“配置文件”(其实就是一段代码)就可以,然后通过服务端的程序读取这个“配置文件”,就知道相应的顺序了,这样总比,连通服务器读取相应的表,来的要快。
如果非要用数据库解决,那我们做一个假设,有100项,某人将所有的项目变成了从后往前倒着写的,也就是第100项与第1项位置互换,第99项与第2项位置互换,这样,那么最后是第50项与第51项调换,也就是100项完全变换了位置,那么不管你怎么存储,怎么读取,这些项都必须全部保存起来,因为每一项的顺序都变了,所以这个方案并不是十分好。
当然,如果非要这么做的话,那么有一个稍微简单一点的办法,不过也需要前端的配合而且,很可能出现征用的情况,使用效果也不一定能太好。
我的办法是建立userid 10001 10002 10003 这样一张表,说白了就是一张以默认顺序ModuleID(个人觉得这个可能是你的表头代码,如果不是不要介意)为字段名的表,然后每条用户id,对应一组编号比如(默认编号为1,2,3,4):
userid 10001 10002 10003 10004
14 3 1 2
221 4 3
31 2 3 4
类似于这样就能直接得到用户的编号顺序了,不过这种还是不如在前端一个配置文件来的舒服(用户修改配置文件后,服务端也会备份(类似于上表这种也可以作为一个客户端配置的备份),但是这种备份比直接修改数据库要要省事不少,至少节省了数据库的资源),而且可能出现征用的问题,比如两个人或更多的人同时修改代码,那么一张表不可能让这么多人同时update,肯定要出现征用,那么服务体验就不会太好(备份的话,不用那么及时,所以征用的可能性不大,即使出现也是发生在后端,用户的体验并没有什么影响)。
以上均为个人理解,共同探讨。
# 设置游标类型,默认游标类型为元组形式
# 将游标类型设置为字典形式
cursor = db.cursor(cursor=pymysql.cursors.DictCursor)
MySQL支持JSON数据类型。相比于Json格式的字符串类型,JSON数据类型的优势有:
存储在JSON列中的任何JSON文档的大小都受系统变量 max_allowed_packet 的值的限制,可以使用 JSON_STORAGE_SIZE() 函数获得存储JSON文档所需的空间。
在MySQL8.0中,优化器可以执行JSON列的局部就地更新,而不用删除旧文档再将整个新文档写入该列。局部更新的条件:
JSON数组包含在 字符 [ 和 ] 字符中,其中为一个由逗号分隔的值列表:
JSON对象包含在字符 { 和 } 字符中,其中为一组由逗号分隔的键值对,键必须是字符串:
在JSON数组和JSON对象的值中允许嵌套:
下例中向创建一个只有一个JSON列的表格 t_json ,并向其中添加JSON值:
若添加的值为非JSON格式,则报错:
查看 t_json :
如果传入的参数不能组成键值对,则报错:
因此我们也可以使用以上三种方法向表中添加JSON值,可以一定程度地避免输入格式错误:
解析字符串并发现字符串是有效的JSON文档时,它在被解析时也会被规范化。对于重复的键( key ),后面的值( value )会覆盖前面的值。如下:
这种“覆盖”在向JSON列添加值时也会发生。
在MySQL8.0.3之前的版本中,与此相反,对于被重复的键,它的第一个值会被保留,后添加的值则会被抛弃。
MySQL8.0.3及更高版本中,有两种合并函数: JSON_MERGE_PRESERVE() 和 JSON_MERGE_PATCH() 。下面具讨论它们的区别。
合并数组时, JSON_MERGE_PRESERVE 只保留最后传入的数组参数,而 JSON_MERGE_PRESERVE 则按传入顺序将数组参数连接。
合并对象时,对于重复键, JSON_MERGE_PRESERVE 只保留最后传入的键值,而 JSON_MERGE_PRESERVE 重复键的所有值保留为数组。
在了解搜索和修改JSON值之前,先来看看JSON的路径语法。
JSON_EXTRACT 提取JSON值,直接看例子:
JSON_REPLACE 与 JSON_SET 的区别:
JSON_INSERT 和 JSON_SET :
JSON_REMOVE :
可以使用 = , <, <= , >, >= , <>, != ,和 <=>对JSON值进行比较。
JSON值的比较先比较值的类型。如果类型不同,则直接 返回类型的优先级的比较结果;如果类型相同,再进行值的内容的比较。
OPAQUE 值是不属于其他类型的值。
转换规则为:
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)