> Plus I feel I would be remiss in not
> exploring an
> alternative to the serial key.
why? it is a tried and true method.
> I can always
> regenerate my primary key
> from the data which is impossible with a serial key.
why on earth would you need to "regenerate" the
primary key? it is used to link related data in
different tables, not as some sort of meaningful piece
of data all by itself.
even if you wanted to "regenerate" the primary key,
using a serial is still easier. under the hash
scheme, you have know the *exact* address...
including abbreviation, periods, etc...
if you use a serial, you could query the table using
SQL's LIKE clause and get all the serial results that
match the string you entered. if you enter the
*exact* address, you'll get a single result - unless
that address is entered twice. you can avoid that
possibility by making address a unique column.
when you link tables together, you can visually one
big table with all the linked data... and that's what
you can get when you join the tables.
if you know one column's information (or part of it
using LIKE), you can return any desired result in the
same row (LIKE might return more than one result).
> I believe the
> risk of collision using md5 is effectively zero on
> this data and I can
> put a unique index over it.
why risk it? what if you are wrong?
> I'm kind of new to sql so apologies if this is a
> naive approach.
> Thanks to all for responses.
no worries. i'm learning a ton as time goes on,
myself. i do think you are over thinking this issue a
bit, though.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
