前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【HoorayOS】LZ带你了解hoorayos的桌面信息存储方式

【HoorayOS】LZ带你了解hoorayos的桌面信息存储方式

作者头像
胡尐睿丶
发布2022-03-28 14:37:47
3760
发布2022-03-28 14:37:47
举报
文章被收录于专栏:代码小睿代码小睿

今天LZ就带大家来了解下hoorayos里,桌面的信息是如何存储在数据库里的

  头两版,hoorayos还只有app而已,数据的记录方式很简单,就是字符串相连的方式,因为桌面的所有应用都来自tb_app表,只需将主键id用“,”串起来即可。如:

代码语言:javascript
复制
2,3,45,5,7,11,21,43

  随后,引入了文件夹功能。问题就来了,桌面上就不单纯是app了,还会有文件夹,而两种类型的应用数据来自不同的两张表,如何记录桌面数据到一个字段里,成了一个头疼的问题(不能分开记录,因为桌面图标是可以拖动的,也就是所有应用都是穿插在一起有排序的)。后来LZ想到个笨方法,就是将tb_folder表(也就是文件夹表)的主键id起始值设的很大,比如1000000,这样LZ还是用原有的方式记录,凡是值大于1000000就代表文件夹,反之就是app。如:

代码语言:javascript
复制
2,3,45,1000001,5,7,21,43,1000003

  但此时对数据库查询的时候,就不能用这样的sql直接查询了

代码语言:javascript
复制
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()”,倒不如将应用类型也存放进来……于是乎,最终的格式可能会变成这样了:

代码语言:javascript
复制
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吧

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2012-08-04 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档