|
I'd be willing to bet that 99% of the riddiculous delays stem from either them being stuck with db related functions that don't fit their needs or they are not realizing(not testing) the code with large collections is so slow...
The simplest indication of a lack of optimization is the time it takes to redisplay a collection when the sort is changed. If the sort order was maintained as changes were made to the db and the sorts stored as indexed linked lists of pointers to the next/previous record it would be lightning FAST! Even adding or deleting items from the index would be fast as you need only change the fwd pointer in the record prior to the new item and the backward pointer in the one that formerly was pointed to by the fwd pointer. Granted with three fields to choose from you have to maintain three indexes and 2 pointers for the beginning and end of each sorted index if you'd like to be able to travel them in both ascending or descending sort orders, but that's not a lot of overhead for the presorted speed advantages.
If they are doing that and are still slow I'm clueless to what they are wasting time doing. Back in the day, late eighties, I had this sort of database system implemented on an Apple ][+ with thousands of record entries for a business and it flew considering the hardware and interpreted BASIC limitations...
|