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. And the user does
have control over this field, although I could introduce some sanity
checking to force uniqueness if I wished.
However, I am in the happy situation of creating this application
for exactly one user whose use of the app is under my control, and I
have tested how it reacts with this "quasi-unique" order number as
the ID and it seems to do very well.
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. 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. I'm sure this
statement will come back to haunt me some day...
Then I'd say that your order number meets all the criteria of an "id"
property. (Notice that it said they're *typically* not under user
control; that's not a requirement.) If there's a requirement that
they be unique, then that's plenty unique for "id"'s purposes, even if
the requirement isn't enforced in code. (Though, as M. Juran points
out, it would be useful if it were.)
