Hello, Walter.

>>So the way to locate an AR document is using doc_type + invoicing_place + inv_number + damned_letter. Not a very nice natural key, uh?
>
>So the problem lies in modifying table structure and programlines. Well, shit happens. You can't avoid this entirely with surrogate keys (you still have to modify table structure and programlines). Maybe when this occurs it is a good time to declare the existing PK (former intelligent invoicenumber) as surrogate and add a new field for the new representation of the PK (just as much work as you would have with surrogaste keys).

Of course one have to modify some code, but if you are using surrogates, you just need to change the places where the complete invoice ID is used, and you don´t have to do ANY change to the related tables and their management.

>You've pointed out a significant advantage of surrogate keys in most (R)DBMSs (some use domains which makes it possible to address all related fields in one place). Though in the same line there is a significant disadvantage when forced to use surrogate key. See the message to chris in this thread regarding the city issue.
>
>Here the disadvantage of using surrogate keys might be even more than the advantage in your case.

I can't understand what you're referring in the last statement. For me the later is a long list of intelligent keys' PROBLEMS.

...
>>Local particularities, differences in fiscal and business customs, etc, are a STRONG point to FORCE use of surrogate keys, in my humble opinion.
>
>We strongly disagree on this point.

Why?


See you,