>>>And I do not want to be 'condemned' by others whenever I myself decide to use meaningful keys. It is the condemnation that is most of the times too hastily done.
>
>No condemnation, but we're in the vein of "best practices", so I'm trying to talk about the rules. I have been known to break a few <g>, because I believe there are times that the purity of perfect normalization is more trouble than it's worth.

What I'm trying to make clear here, is that using meaningful keys is not 'breaking the rules' and using meaningless keys is not a sign of purity. Perhaps that is also true of some of your other 'breaking' practices?!

[snip]
>>In a same vein, a meaningful key either should have no reason to change, ever. The design should guarantee that the invoice ID will never change after it has been created. In case the date appeared to be wrong, a counterbooking or deletion should be done and a NEW invoice should be made. In case the client wants to be able to later alter the date of that specific invoice, my advice would indeed be to not include the date in the invoice ID.
>
>I'd have to disagree there. Because the meaningful key contains data (whether it's actually used that way by the system or not), there is a chance it can change. I don't want to delete an entire invoice and recreate it just to change an invoice date! With a surrogate key, that won't be a problem. Just change the date and go have your cup of coffee. I'm not saying meaningful keys are *never* justified. It's just that I avoid them as much as possible.

So, we do not disagree, as I see it. If you were that client I was referring to, I'd dissuade the use of the date in the key and advice a surrogate key. However, there may be laws that prohibit the change of a date in an already sent invoice. If that's the case, the client must stick to that principle.

>Hey, good discussion.

Yeah. Pity that not so many others have participated. They are all mainly occupied by political debates and smalltalk. :)