In a message dated 12/23/2010 4:28:38 PM Pacific Standard Time, [email protected] writes:
> > SQL uses indexes. MV uses cross references to item-ids (MV sometimes > supports indexes, but they don't always work as well as in the relational > world.) > > > > I don't know as that is true ... or are you using the word "index" to > mean something completely different to me? I'll agree the implementation > of indices can be buggy, but surely that's true of relational engines too? > I'm not quite sure I'm confortable with the idea (expressed in the prior-prior posting of which I here quote and enquote the reponse) that MV uses cross-references to item-ids. To me a hash table, isn't the same thing as a cross-reference which sounds a lot like a secondary key. Hashing calculates an exact jump point at which a group of related records are kept. They are related by having the same hash value. But the hash value itself isn't looked up, it's a calculation. I wonder if you can setup a first normal form table in such a way, that it maintains a constant sorted order ? Sorting on the primary key, would then be merely display time bound, there is no effort to it. I suppose you could even pick up and lay down the database periodically so the sort order matches the actual disk layout. Pick could never do something like that. There is always going to be effort involved in any sorting, even if you're simply traversing the index tree and grabbing the underlying data records. But back to reality, I don't think SQL works this way anyway. The perception that it sorts much faster is probably related more closely to the horsepower behind the scenes. Pick systems tend to be installed on slower systems because they are so efficient and most users are cheap with their database, and expensive with their graphics. So they install the SQL type databases on speedy machines. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
