※ 引述《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)