Re: assigning primary key on insertion
Re: assigning primary key on insertion
- Subject: Re: assigning primary key on insertion
- From: email@hidden (Anjo Krank)
- Date: Wed, 21 May 2003 00:40:21 +0200
Am Mittwoch, 21.05.03 um 00:04 Uhr schrieb Deirdre Saoirse Moen:
You may not care about this, but I've seen it create more than one
fracas, so I'll point out the potential downside of this: assigning
the primary key in advance inherently means there will be holes in
primary key sequence numbers. Now, usually, that's not an issue, but
if one of your primary keys is, say, "invoice number" and someone
suddenly wonders why one record is "missing," it can create a lot of
extra work.
There is *tons* of discussion on the list on this topic and the general
consensus has been for years that it it never, *ever* a good idea to
have PKs or FKs with a meaning - neither explicit like the SSN nor
implicit like the "holes" in the "order" of invoice numbers. And this
is not special to WO anyway. I will not recap this but rather advise
you to check the archives.
From my experience, an invoice number is some combined CUSTOMER-ID,
YEAR/MONTH and running number anyway. If you want to check for
duplicates on the fly without the user switching the page, test the new
ERXJSInputValidator from Wonder.
Cheers, Anjo
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.