Ben Hencke wrote :

> I would really reccomend that you stay away from hashing at all. Never
> hash a serial number that already fits into a reasonable ammount of
> space. Hashing is really only useful when trying to take a
> large key of data (ie a string, file, whole record, etc) and make it into a
> new key that can be easily sorted/indexed/etc.

A hash index isn't ment to keep records "sorted" at all.
A hash index should be used when you need optimum performance
in retreiving a single record from a table. A properly designed
hash table/index should be able to retreive a specific fully
qualified record in one single I/O. A b-tree needs as many I/O's
as there are currently "levels" in the tree.

On the other hand, if you need range retreivals (using part of the key),
a B-tree is far better and a hash index sucks...

This applies to databases in general, maybe not to the case at hand.

So there is no "best" here, it, as usual, depends.
And the size of the key has not much to do with this decision.

> A card # that is 1 to 10 milion
> already fits nicely into 24 bits. Hashing this small ammount of data
> will only complicate things.

Maybe, but a hash it gives the fastest retreival of the record.

Jan-Erik

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics