※ 引述《mikechen (mike)》之銘言： : ※ 引述《TonyQ (沉默是金)》之銘言： : : SELECT std_case, std_name, std_sch, : : CASE std_case : : WHEN '班內' THEN 1 : : WHEN '詢問' THEN 2 : : WHEN '試聽' THEN 3 : : WHEN '流失' THEN 4 : : ELSE 5 : : END : : FROM `student` : : ORDER BY 4 asc : :個人是覺得如果可以簡單的事情 , 就不要太複雜了. : select case 雖然可以解決問題，但不一定是最好的方法， : 假設你的資料量是數萬筆，需求臨時改變其中幾個順序， : 反而實務上使用第一種自建index方法比較好維護， : 改SQL指令會改到死，提供參考 : 解決問題不一定只用聰明方法，有的時候笨一點會更好 方法不只一種 , 就都提出來討論囉 , 況且也不一定會有這種需求 , 幫使用者提前考慮到這種需求 , 或許才真是聰明路呢. 不過 in this case , 我看不出來為什麼需要臨時需要針對一兩筆改動時 , build table 來關聯的作法會比這個case法來得容易修改. (先假設這是調用view或是調用點只有一個的前提的話.) 是因為 db 資料比較好一次調整大量的數字來排序 ?.? 如果說類別很多那真的sql maintain起來會比較累 , 在這個 case 類別只有四個 , 就算資料量有百萬筆 , 要異動這類別的排序也不難. 如果是字面上的針對其中一筆資料來作異動而不是 by 類別 , build table 的作法在這裡也是針對類別 , 對於其中挑選其中單一筆資料的排序並無幫助啊... 反而是select case 還可以比較方便針對特定 id 或其他資料來作判斷. 這篇文章實在是看得讓人很困惑 , 是我誤解了什麼嗎 XD 站在個人想法是認為每次 query 要多 join 一個table實在很不划算 , 直接用算的比較經濟 , 當然這問題還是要取決於實際的問題需求囉. -- What do you want to have ? / What do you have? 從書本中，你可以發現我的各種興趣。 從ＣＤ中，你可以瞭解我所喜歡的偶像明星。 或許從文字你很難以瞭解一個人，但從物品可以。 My PPolis , My past. http://ppolis.tw/user/Tony --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 221.169.78.140 ※ 編輯: TonyQ 來自: 221.169.78.140 (05/18 11:50)