>My dear Walter,

Oh, now I have to be worried ;-).

>>>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.
>
>You are not reading, I'm afraid. When the key becomes bloated, beside the changes to the scheme, the data have to be reprocessed (in most cases), and the underlying code to handle the added fields or different size have to be propagated trough ALL your application. That DOESN'T happen with surrogates.

If you do analyze this, it may not be that worse than surrogate keys. For example each object which has to display the surrogate key has to be modifies anyways. whether the datasource is in the child or parent table, it does not matter. When talking about view where this intelligent key occurs: they have to be modyfied also whether you use intelligent or surrogate keys.

The only difference is that the retrieval and writing of those childrecords have to be modified. If having a flexible routine that does this for you, You'll not have much nightmare from that either.

And yes, I'm listening.

>>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).
>
>I have replied this in a previous post where I find your example. Yout turn to search for mine. 8-)

I'll do at a later point.

>>Depends on the case.
>
>It doesn't depends. Giving the same functionality, scope, performance, and the likes, any system designed and implemented in a consistent way it would be far more easier to document, mantain and extend. Want me to sign it? 8-)

I don't have problem with this statement, though I've got a problem with what is called consistency.

Walter,