84669 人が学習中
152542 人が学習中
20005 人が学習中
5487 人が学習中
7821 人が学習中
359900 人が学習中
3350 人が学習中
180660 人が学習中
48569 人が学習中
18603 人が学習中
40936 人が学習中
1549 人が学習中
1183 人が学習中
32909 人が学習中
我在前台接到很多组数据,A1,B1,A2,B2...其中A(时间)和B(内容)的性质都一样,在数据库我只想用一个text字段存着就算了,因此他们之间要个字符进行分隔,用的时候再分割字符串,但不知用什么字符好,又怕这个字符和B里的内容相同,分割出错,给个建议
人生最曼妙的风景,竟是内心的淡定与从容!
不考虑索引和性能的情况下: 1 如果每个内容的类型都都是数字或无分隔符的汉字,可以用逗号或分号分割,如1,2,3 或 欢乐,悲伤,如果需要用到Like,则要这样用,1,2,3,(注意开头和结尾都有分隔符) 2 如果内容为带符号的字符串或多种类型,将其序列化为JSON或XML来存储,如{time:2014-05-06,content:"中国人民,代码什么的,都好像不是什么问题,。。。。"} 3 如果楼主实在想存在一起,用多个特殊符号分割如2014-05-06@@"中国人民,代码什么的,都好像不是什么问题,。。。。" 但是,以上方式无法使用索引 换个思路,为什么要这么存? 1 A1,B1,A2,B2...其中A(时间)和B(内容)的性质都一样?时间和内容的性质怎么会是一样的呢,这个保存下来后,要根据时间或内容做查找吗?如果要,那么楼主的方案是不对的,而且根据楼主的说法,恒定有A,B两个字段,为什么要存在一起呢? 2 如果A1,B1是动态字段,那么如果楼主是否有根据条件筛选的需求呢?如果只是简单的搜索,那么可以尝试下数据库+全文检索,如果需要做字段筛选,如时间段筛选,考虑Redis来实现该块业务,如果频繁出现,考虑设计上抽象合理性或考虑MongoDb这样的数据库
不知道{key:value}这种形式适不适合你用,因为感觉JSON的格式load回来会比较方便,而且格式也可以做检查,大多数语言都支持... 不过不就用两列呢,这样你这些事都不用做了...´・ω・`?
自己顶一个分隔符,取回的时候按照定义来分割,
如果场景允许,也许可以尝试尝试 K-V 型存储结构的数据库。
还是把这个这个数组serialize后存入数据库中吧
不考虑索引和性能的情况下:
1 如果每个内容的类型都都是数字或无分隔符的汉字,可以用逗号或分号分割,如1,2,3 或 欢乐,悲伤,如果需要用到Like,则要这样用,1,2,3,(注意开头和结尾都有分隔符)
2 如果内容为带符号的字符串或多种类型,将其序列化为JSON或XML来存储,如{time:2014-05-06,content:"中国人民,代码什么的,都好像不是什么问题,。。。。"}
3 如果楼主实在想存在一起,用多个特殊符号分割如2014-05-06@@"中国人民,代码什么的,都好像不是什么问题,。。。。"
但是,以上方式无法使用索引
换个思路,为什么要这么存?
1 A1,B1,A2,B2...其中A(时间)和B(内容)的性质都一样?时间和内容的性质怎么会是一样的呢,这个保存下来后,要根据时间或内容做查找吗?如果要,那么楼主的方案是不对的,而且根据楼主的说法,恒定有A,B两个字段,为什么要存在一起呢?
2 如果A1,B1是动态字段,那么如果楼主是否有根据条件筛选的需求呢?如果只是简单的搜索,那么可以尝试下数据库+全文检索,如果需要做字段筛选,如时间段筛选,考虑Redis来实现该块业务,如果频繁出现,考虑设计上抽象合理性或考虑MongoDb这样的数据库
不知道{key:value}这种形式适不适合你用,因为感觉JSON的格式load回来会比较方便,而且格式也可以做检查,大多数语言都支持...
不过不就用两列呢,这样你这些事都不用做了...´・ω・`?
自己顶一个分隔符,取回的时候按照定义来分割,
如果场景允许,也许可以尝试尝试 K-V 型存储结构的数据库。
还是把这个这个数组serialize后存入数据库中吧