View Single Post
  #6 (permalink)  
Old July 27th, 2008, 04:31 PM
Old Pedant Old Pedant is offline
Friend of Wrox
 
Join Date: Jun 2008
Location: Snohomish, WA, USA
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

I think I have to disagree, slightly, with Imar.

I just don't even begin to understand the point Imar was trying to make here:
    The problem is of course, that if you page in the database,
    you only get back the relevant records for the requested page.
    If you then try to sort, you only sort the current page.


Why???? I certainly would never do that. Why would you want to do that??? (Or is Imar specifically talking about the techniques used in the links he posted? That is, that's a limitation of the code he shows?)

If you want to implement completely dynamic sorting, then every time the sort is changed, you *need* to go back and re-sort the *entire* set of records.

Now, if that set of records is small enough, then the right thing to do is sort them in the browser, without ever going back to the server. Yes, even if the set of records is paged.

To give an example: 100 records, shown via 10 records per page. Absolutely no reason not to do all paging *AND* all sorting completely in the browser, completely in JavaScript. Takes the load off the server. And it's really not hard to do. I thought I had a demo of that, but all I have is a demo of sorting, no paging. Still, take a peek here:
http://www.clearviewdesign.com/clear...bie/demos.html
and especially here:
http://www.clearviewdesign.com/Newbi...TableDemo.html
(You can tell by the dates used that this is a pretty old demo. It's ASP, not ASP.NET, but would be easy to convert to ASP.NET. You could either do it brute force, starting from a DataReader, or by creating a custom component.)

If you do *NOT* opt to go the all-browser route, then I don't understand why you would *NOT* choose to go the all Stored Procedure route. After all, when the user calls for a change of Sort, you really have no choice but to re-order *ALL* the records and then start over again with Page 1 of the re-ordered set. (With only a little more difficulty, you *COULD* allow the user to designate a "current record" and then re-order and then find the page contaiing the "current record" within the new pages. But I don't even know if I've ever seen a site that bothered to do that, and I am doubtful that it's worth the effort.)

Anyway, given that you will go back to Page 1 of the re-ordered set, who cares what the prior set of records was? Why retain them, at all?

I think you will find that the really "big guys" in this business (e.g., the Amazon.com's and EBay's of the world) do it this way. They don't even *attempt* to keep any sort of per-user "state" of recordsets (data tables, whatever). Instead, they just let the DB find the next set of appropriate data, however it is requested.