>Hi, Walter.

>>>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.

>>Changing the related tables won't be the biggest a problem IMO. Broken views and program lines are. They occur in both using surrogate and intelligent keys.

>Changing the related tables IS a problem. You have to consistenly add/change all the affected fields, indexes, AND the code that handles this. Using surrogates you have to update JUST the code that handles the patent table search trough the candidate key. The rest is left unchanged.

The database schema is not a problem at all. It generally takes just a few minutes to do this.

>>To what are you refering ? Do you agree that in the "city" case an intelligent key solution (case A) might be the best choice ??

>No. I disagree here too. If you need your system to be used everywhere, you can't use any sort of intelligent key.

But it is the most easy one to implement. With this intelligent key solution I don't have to manage the complexity that comes with surrogate keys. (note that this same argument is used in favour of surrogate keys in other cases).

>ZIP codes are different in every country (indeed they are not called ZIP codes in most places, and in many it doesn't even exist).

Up here, they don't exist either.

>>All these issues can be handled with intelligent keys. I've seen ERP software which almost exclusively uses intelligent keys (Navision). Since it works, and is highly adaptable and I don't see any proof in such a statement.

>I already know that you can go that way. Indeed, our ERP suite actually still USES intelligent keys in some places. But this is because there are lots of legacy code that we don't have time or resources to change.

Navison Financials, is a Windows based product only about 3 or 4 years old. Legacy code does not exist here.

>Is it desirable. NO! Every time we have to mantain that old code, we either change the keys, or had a painful coding journey. We have to use old classes to handle this data that are a lot more complex to use that the newest ones, just because it's not consistent with our new framework.

Hmmm, I see a heterogenous environment comming up !!!

>Indeed, the way you code doesn't implies at all the usefulness of your final product. But when you start thinking in productivity, documentation and flexibility on the long term, things change.

Depends on the case.

Walter,