Re: Natural keys vs Aritficial Keys
Date: Mon, 18 May 2009 17:06:42 GMT
>>> Speaking of efficiency, composite primary keys have almost no effect, if you get the indexes right. <<
> Ever work with DBs that use hashing instead of tree indexes? Longer
> keys are better because there is less chance of a hash collision.
> There is also a lot of work being done on minimal perfect hashing
> right now. This is going to be very important for VLDB because
> unlike indexes, a hash requires only one probe.
Every so often some crackpot claims to have discovered the perfect hash but bigger keys usually need bigger buckets to reduce collisions. It reminds me of the old joke about the guy who kept re-running his compression program in hopes of reducing the file's size to one byte. Hash indexes are okay for some special purposes, such as an atm withdrawal system but they are more common in various interpreters. Same goes for column-based stores, not to mention the trans-relational "model". Meanwhile, cpu design has been stagnating for years, either improving self-created problems or being almost totally reliant on bio-feedback, optimizing patterns that are found in typical software when the typical software uses only the features of the previous hardware generation, then the cycle repeats with the software designers doing the same thing in reverse. There's still no consumer machine with a double-ended stack which is an obvious requirement with so many systems being interpretive now, the Intel segmented memory which started out as a hack for backwards compatibility would be tremendously useful on today's big memories, as ironic as that may sound. Windows and Linux didn't hide segments from the developer and there is no mainstream cpu with any kind of memory association feature beyond traditional physical addressing. Received on Mon May 18 2009 - 19:06:42 CEST