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