On Aug 15, 2008, at 11:45 AM, Florijan Stamenkovic wrote:
With any such value there is some probability the client will (next
week or next year) want (a) to edit it, (b) in some special case,
to have non-unique values.
Aaaaaah, I love being an in-house developer that can just stamp his
foot and say no, without having to think about such a thing as:
clients :)
That -- same as an extra UNIQUE column -- would not satisfy the
demand that "all numbered orders make a sequence 1,2,3,4,....". The
client would prefer that the sequence is without gaps (not
something like "1,5,6,27,....").
I start to see your point. It makes it very tedious to deal with
however. I've been in this situation. The decision (based on my
selfless recommendations :) was not to care that 1,2,3,7,10... is
ugly. They are unique. They identify things persistently. Sold.
As for Chuck's solution, also notice that it does not help you deal
with the potential demand for edibility. And since it doesn't, you
might as well use PKs (or a separate db generated sequence) in a two
table setup in which you would still get the sparse but linear
sequence like in Chuck's solution, but with far less fuss.
I think my solution would avoid gaps. The Order and OrderNumber are
updated in the same transaction so there should be no rolling back of
the number after another order has used a higher one.
I think you simply will have to make compromises.
That is the easiest way.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
