今天LZ就带大家来了解下hoorayos里,桌面的信息是如何存储在数据库里的
头两版,hoorayos还只有app而已,数据的记录方式很简单,就是字符串相连的方式,因为桌面的所有应用都来自tb_app表,只需将主键id用“,”串起来即可。如:
2,3,45,5,7,11,21,43
随后,引入了文件夹功能。问题就来了,桌面上就不单纯是app了,还会有文件夹,而两种类型的应用数据来自不同的两张表,如何记录桌面数据到一个字段里,成了一个头疼的问题(不能分开记录,因为桌面图标是可以拖动的,也就是所有应用都是穿插在一起有排序的)。后来LZ想到个笨方法,就是将tb_folder表(也就是文件夹表)的主键id起始值设的很大,比如1000000,这样LZ还是用原有的方式记录,凡是值大于1000000就代表文件夹,反之就是app。如:
2,3,45,1000001,5,7,21,43,1000003
但此时对数据库查询的时候,就不能用这样的sql直接查询了
select * from tb_app where id in(2,3,45,1000001,5,7,21,43) order by field(id, 2,3,45,1000001,5,7,21,43)
LZ必须先将字符串拆分成两组数组,一组是app,一组是folder,然后分别查询对应的表,最后将返回记录再按照原先的顺序拼装成数组返回。
虽然很蛋疼,但是LZ还是很享受的。
但这样的操作模式依旧有一个很极端的弊端,就是folder的主键id目前是设为1000000为起点,如果app的数量超过1000000个,桌面展示数据就会彻底错乱掉,并且很难修复,如果没有备份数据,那就死定了 _(:3」∠)_ 死定咯死定咯
虽然这个弊端遇到的几率很小,但还有个问题,就是不容易扩展,如果桌面除了app和folder,还需要增加其他的种类,比如用户上传图片保存到桌面,这时候就会增加一张tb_image表用来存储用户的图片,难道又要像folder一样,规定一个区间的id给图片用么?
像LZ这么聪明又这么最求完美的正太怎么会继续使用这么笨的方法……
接下来的内容,还未在新版本中体现,还处于开发和LZ的意淫中
LZ最后想到的办法就是,为毛只用id啊,反正也不能用“where id in()”,倒不如将应用类型也存放进来……于是乎,最终的格式可能会变成这样了:
app_2,folder_1,image_234,mp3_3,av_7142
这样一来,避免的那个极端的弊端,同时还不怕你扩展,想增加什么类型,只需指定好规范,比如image表示图片,对应tb_image表;mp3表示音乐,对应tb_mp3表;av表示……
至于前台嘛
LZ会将类型和id分别存储好,对应type和realid,这样不管是获取类型还是id,都会很方便。
OK,这就是LZ的整个思路,如果你有更好的解决方案,楼下留言告诉LZ吧