From: ldo@nz.invalid   
      
   On Sun, 18 Jan 2026 17:20:27 -0500, Cryptoengineer wrote:   
      
   > On 1/18/2026 4:44 PM, Lawrence D’Oliveiro wrote:   
   >>   
   >> It should be possible to choose the collating sequence for the   
   >> retrieved results as part of the query, rather than relying on a   
   >> fixed one assigned when the records are stored.   
   >   
   > Its easy to forget that there's a resource issue here. Ordering   
   > once, and then storing in that order may be inflexible, but it   
   > greatly reduced the resources needed to make a retrieval.   
      
   That may have been true back in the days when you paid by the hour to   
   access expensive online query services that gave you back the data   
   over slow modem connections (not to mention the expense of a phone   
   call for that connection).   
      
   As an apt example, I was thinking of how much resources it would take   
   to store a phonebook nowadays: an entire city could be covered with   
   just a few tens of millions of records, tops. And users wouldn’t want   
   to look at them all, they would want to filter by entering part of a   
   name or address or whatever, typically returning maybe a few hundred   
   records at most. (Who wants to scroll through more than that?)   
      
   Back-end query languages can offer quite sophisticated sorting   
   options. But if that isn’t enough, it’s easy to retrieve the full   
   record set for such a query, and then apply further sorting in the   
   front-end app. Such sorting could even be applied in JavaScript   
   running locally in the browser: the user just clicks on a column   
   heading to instantly see the record set sorted by the selected key,   
   no further traffic back to the server necessary.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)