之前在某專案上採用前後皆是接 API 的方式來撈資料,說是時程趕,所以幾乎所有的資料都是夠過 Call Store Precedure,當時在處理後台的列表部分,覺得分頁非常難寫...,後來找到很多 Source,不過都寫得太複雜了,最後給大家參考這篇 洞庭小虾 - mysql 分页存储过程 ,算是非常基本款的分頁寫法,不錯用了。
這個分頁的寫法很適用在只撈同一張 Table,或是查詢, 排序,皆可,因為查詢排序都是靠 GET/POST 參數去判斷怎麼串參數到 Store Precedure 而已,重點就是只能撈同一張 Table,這樣這隻 SP 就能走整個後台所有的列表。
但是如果某列表的邏輯需要 Join 其他 Table,那麼你就要複製這隻 SP,另外客製出只符合這個列表的 SP 了,也就是說,就很難拿出來共用了。
比方說產品列表,如果只單純撈產品那張 Table 的東西,那麼這隻 SP 適合用,但是如果產品列表還需要 join 『產品規格』列表的資料進來,那這隻 SP 你可能就要拿出來改一改了。
執行這隻 SP 要記得把 OUT 接出來,可以得到總數,進而算出總共有幾頁。
就是這樣,分頁好煩 (當時覺得 ORM 是天堂),想要一隻 SP 打整個後台的列表,我看是容易 GG 的成分比較高,就算只能寫成一隻,那應該很難維護,可能寫到連自己都看不懂,想到就頭麻...,如果大家有更好的方法也歡迎讓我知道,雖然我很不習慣寫 SP xdd。
這個分頁的寫法很適用在只撈同一張 Table,或是查詢, 排序,皆可,因為查詢排序都是靠 GET/POST 參數去判斷怎麼串參數到 Store Precedure 而已,重點就是只能撈同一張 Table,這樣這隻 SP 就能走整個後台所有的列表。
但是如果某列表的邏輯需要 Join 其他 Table,那麼你就要複製這隻 SP,另外客製出只符合這個列表的 SP 了,也就是說,就很難拿出來共用了。
比方說產品列表,如果只單純撈產品那張 Table 的東西,那麼這隻 SP 適合用,但是如果產品列表還需要 join 『產品規格』列表的資料進來,那這隻 SP 你可能就要拿出來改一改了。
執行這隻 SP 要記得把 OUT 接出來,可以得到總數,進而算出總共有幾頁。
就是這樣,分頁好煩 (當時覺得 ORM 是天堂),想要一隻 SP 打整個後台的列表,我看是容易 GG 的成分比較高,就算只能寫成一隻,那應該很難維護,可能寫到連自己都看不懂,想到就頭麻...,如果大家有更好的方法也歡迎讓我知道,雖然我很不習慣寫 SP xdd。
沒有留言:
張貼留言
若你看的文章,時間太久遠的問題就別問了,因為我應該也忘了... XD