Yeah thanks for the feedback, I'm already including a primary key auto_increment field in place to tie the tables together with an ID I *know* will be unique. This other ID scheme is just to work within their existing system that uses this. I'm just trying to mirror/maintain that scheme for their purpose.
--- Miles Thompson <[EMAIL PROTECTED]> wrote: > > > For the original poster: Having said all this, make > certain that there is > a unique, system-generated, primary key for each > table. As these keys > *never* have to be seen by the public, don't get > tampered with, etc., they > can be safely relied on for inter-table > relationships. Down the road they > will save your bacon. > > If the purpose of having separate numbering > sequences for each state is to > keep track of a count, why bother? Just select for a > count on each state. > If it's a matter of ego, in that if I have a lower > registration number I > have higher status, well fill your boots with > whatever scheme will work. > > Really look at this v. closely. Quite often clients > insist on wacko > numbering schemes which they are convinced are > important, but frequently > result only because that's the way it's always been > done. Also remember > there should be no data encoding within a field - > that's why so many > columns are possible. > > Example, membership numbers like MABT082003BM2, > where the first four > characters are my initials, the next six the date I > joined, and each of > the next the colour of my eyes, marital status and > number of children, ARE > FORBIDDEN. All that information belongs in separate > fields. This is what > you are tending towards with AL0003 and KY00107. Bad > practice. > > As I'm Canadian, if I stepped on any toes I'll > apologize in advance. <g> > > Cheers - Miles > > -- __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
