In my case, the order number (which although I say number, is
better represented as a string since it can have a letter after the
number part) is indeed unique within my company, even to the
standards of your librarian. No two orders will ever have the same
number.
But in my application, I have to give newly-created orders
_something_ in this field, even if it's a blank.
If you can't assign a unique ID to a newly-created order when it's
created, then maybe it should be a different class, like an order
request, which has no ID but can be converted into an order (with an
ID assigned at that time).
And the user does have control over this field, although I could
introduce some sanity checking to force uniqueness if I wished.
That would be a good idea if you desire sanity. Can two orders ever
have the same number, or not? You need to choose.
However, I am in the happy situation of creating this application
for exactly one user whose use of the app is under my control...
No comment.
The worst case I can invent is when the user accidently creates a
duplicate ID and comes to me wondering why when he clicks on a
button in Filemaker, it takes him to the wrong order in my
scheduling application.
I would say Don't Do That, then -- to the programmer, I mean. If
it's always wrong for the user to do something, he shouldn't be allowed.
At which time I will say "you made two orders with the same number,
dummy!" and all will be well. (I know this attitude makes many
developers nearly freak out with the shiver shakes but trust me,
until you have programmed for a very small set of users who are
"captive", you haven't lived.
No, the real joy is developing for a very large set of captive users...
