Demystifying the use of CASE in an ORDER BY statement

  • Also, to continue, there is another discussion that seems to expand on the OVER (ORDER BY ...) technique, adding that using function ROW_NUMBER on large tables can be counterproductive. There are multiple solutions in the replies to this blog article:

  • Good article. I often use case in order by. This will give me some new ammunition on how to use it better.

  • My basic question on all this is: yes, but WHY does one need it ?

    Maybe building up an additional field such as a running subtotal ? For a report ?

    My own purpose for dynamic ordering was to allow users to determine the sorting order of a list of invoices to be manually selected for printing. From the SSRS/Report Builder User Interface. Speed and performance of presenting an ordered list in such a case are not really a consideration (a one or two second response time should be adequate and no one really wants to view a list of 1,000,000 items ...). Since new invoices can appear during the time the user is selecting older ones for printing, READ UNCOMMITTED should remain a viable option which should not (I presume, lurching totally above my level of knowledge here) cause blocking.

    So, under which other circumstances would there be a need for high-volume behind the scenes process based on ordering a list ?

    And by the way, good call on Brent Ozar's great link.

  • Ben, I'd like to see you write an article that shows more of what you want/mean about LINQ vs TSQL. I don't know if you're correct or not, but I'd like to see it illustrated.

Viewing 4 posts - 61 through 64 (of 64 total)

You must be logged in to reply to this topic. Login to reply