My highly estimated Walter,

>>My dear Walter,
>Oh, now I have to be worried ;-).

better this way? 8-)

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

You are trying to turn down my argument saying the same I said, but falsing the argument. You HAVE to rewrite some parts where you actually are letting the user enter the alternate (intelligent) key, but you DON'T have to rewrite all the child handling, and in a slightly complex system, this can be a daunting task, that you are underestimating. More over, as a key gets more complex, you have to make sure in your code that the added fields that get into are consistently completed.

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

I can't imagine what's a "flexible routine" to you, Walter, as you seem to adore inconsistency, I'm afraid just of imagining it.

>And yes, I'm listening.
As I said, you're not reading. 8-)

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