今天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吧。

　　

如果你觉得LZ的解决方案很可笑，那也请你不要笑，因为

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

哈哈哈

.

.

.

.

.

.

.

.

.

.

.

.

完