: 口水到這邊，小弟也來拋磚討論一下好了（雖然我論噗通沉沒的可能性… orz）
: 不知道大家在可排序的資料的資料庫都是怎麼設計呢？
: 例如一本相簿內，相片的排序，普通的建立方式應該就是 id / order 吧，
: 例如： id title order
: -------------------
: 33 相片一 1
: 34 相片二 2
: 35 相片三 3
這問題算滿常見的，應該已經有最佳解了吧？
我沒寫過，但未來有機會遇到，也想知道答案。
不過在還不知道答案的情況下，就來推敲推敲吧！
目前常見的相簿，都有相簿放多個照片，一本相簿可放照片數上限約為200張。
比較少像檔案總管那種無上限的，如果有，應該是不能自訂排序的，
亦即頂多只能依檔名、上傳/修改時間、大小、擁有者等方式排序。
在此我們假設每次要處理的量limit最多200筆。
（原po說1000筆，這種情形看能不能取消自訂，變成可改檔名再依檔名排序，
或是多增加一些「容器」，如tag、頁碼，減少每次要讀取、更新的照片總數）
"photo" table 應該要有個欄位叫album，使得每一張相片可對應至一本相簿。
a.移動單筆時
我猜測原po描述的情況可能是一個列表，有「上下頂底」按鈕，按了之後可以把
目標往上下頂底移動，而不是像臉書相簿可滑鼠拖拉至任意位置。後者感覺比較
靈活，如果前者有個功能可將目標換至指定的第xx位置，那兩者才會比較相似。
假設從頭到尾只處理一個動作，由於使用者瀏覽時，系統已經把該有的資料都撈
出來了，而我們用ajax可以知道使用者要把id編號1對調到2，我會這樣做：
ajax： exchange_photo?from=1&to=2
後端： "update table set pos = 1 where pos = 2 limit 1;"
+"update table set pos = 2 where pos = 1 limit 1;"
(同一個db connection內，一次執行兩個update指令)
b.移動多筆時
我偏好等使用者動作都完畢後，再一次處理。使用者可以隨他高興的拖拖拉拉
上上下下調整照片、拼拼圖、打字，等到他按下「確定」或是離開頁面前，再
把最後的結果儲存起來。如此一來，http request數、db connection次數都
可以儘可能的低，即使sql指令可能會很長、很多。我是覺得控制前者數量比
較重要，sql指令下得好的話，一個指令才耗時0.000x秒，很多個也沒差。
最穩的作法是重新存所有照片順序，也就是不管只變動1張照片、200張照片全
亂掉或反轉順序，我都傳送200張的順序並儲存。
理論上有個作法叫linked list，photo table要有頭、尾兩個欄位，我只要傳
送(所有有被變動的照片的頭、尾)+(被牽連到的上家的尾、下家的頭)……呃，
有可能會搞得很複雜。再者，db似乎無法排序此資料結構，只能捉出來後再用
程式排。
其他作法我還想不到……整個頁面快照、快取？排序好的資料存成某種結構，
json, tree？非關連式db的作法？雲端運算？XDDD
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.122.76.198