今天LZ就帶大家來了解下hoorayos裡，桌面的資訊是如何存儲在資料庫裡的
頭兩版，hoorayos還隻有app而已，資料的記錄方式很簡單，就是字元串相連的方式，因為桌面的所有應用都來自tb_app表，隻需将主鍵id用“,”串起來即可。如：
1
<code>2,3,45,5,7,11,21,43</code>
随後，引入了檔案夾功能。問題就來了，桌面上就不單純是app了，還會有檔案夾，而兩種類型的應用資料來自不同的兩張表，如何記錄桌面資料到一個字段裡，成了一個頭疼的問題（不能分開記錄，因為桌面圖示是可以拖動的，也就是所有應用都是穿插在一起有排序的）。後來LZ想到個笨方法，就是将tb_folder表（也就是檔案夾表）的主鍵id起始值設的很大，比如1000000，這樣LZ還是用原有的方式記錄，凡是值大于1000000就代表檔案夾，反之就是app。如：
<code>2,3,45,1000001,5,7,21,43,1000003</code>
但此時對資料庫查詢的時候，就不能用這樣的sql直接查詢了
<code>select</code> <code>* </code><code>from</code> <code>tb_app </code><code>where</code> <code>id </code><code>in</code><code>(2,3,45,1000001,5,7,21,43) </code><code>order</code> <code>by</code> <code>field(id, 2,3,45,1000001,5,7,21,43)</code>
LZ必須先将字元串拆分成兩組數組，一組是app，一組是folder，然後分别查詢對應的表，最後将傳回記錄再按照原先的順序拼裝成數組傳回。
雖然很蛋疼，但是LZ還是很享受的。
但這樣的操作模式依舊有一個很極端的弊端，就是folder的主鍵id目前是設為1000000為起點，如果app的數量超過1000000個，桌面展示資料就會徹底錯亂掉，并且很難修複，如果沒有備份資料，那就死定了 _(:3」∠)_ 死定咯死定咯
雖然這個弊端遇到的幾率很小，但還有個問題，就是不容易擴充，如果桌面除了app和folder，還需要增加其他的種類，比如使用者上傳圖檔儲存到桌面，這時候就會增加一張tb_image表用來存儲使用者的圖檔，難道又要像folder一樣，規定一個區間的id給圖檔用麼？
像LZ這麼聰明又這麼最求完美的正太怎麼會繼續使用這麼笨的方法……
———————————————接下來的内容，還未在新版本中展現，還處于開發和LZ的意淫中———————————————
LZ最後想到的辦法就是，為毛隻用id啊，反正也不能用“where id in()”，倒不如将應用類型也存放進來……于是乎，最終的格式可能會變成這樣了：
<code>app_2,folder_1,image_234,mp3_3,av_7142</code>
這樣一來，避免的那個極端的弊端，同時還不怕你擴充，想增加什麼類型，隻需指定好規範，比如image表示圖檔，對應tb_image表；mp3表示音樂，對應tb_mp3表；av表示……
至于前台嘛
LZ會将類型和id分别存儲好，對應type和realid，這樣不管是擷取類型還是id，都會很友善。
OK，這就是LZ的整個思路，如果你有更好的解決方案，樓下留言告訴LZ吧。
如果你覺得LZ的解決方案很可笑，那也請你不要笑，因為
.
哈哈哈
完
本文轉自胡尐睿丶部落格園部落格，原文連結：http://www.cnblogs.com/hooray/archive/2012/08/04/2623077.html，如需轉載請自行聯系原作者