Martin:

I changed the paragraph order of your response because I want to answer the
most important stuff first.


> What do I have when someone ask me for help about this topic?

Please answer what you believe is right and state your reasons behind this
belief. Someone may pick up the opposite side and, if so, the original poster
needs to evaluate both sides of the argument before making a decision. If the
original poster evaluates a response before using it, I have accomplished my
primary goal.

The fact that I very strongly disagree with you on this issue should never stop
you to answer what you believe is correct. There would be no point for me to
be on UT if no one was writing stuff that I don't know anything about or don't
agree with. I answer a lot more questions than I ask but it certainly does not
imply that I am not learning something every day.


>> A total lack of vision??? You seem to be the one making the assumption that
>> all applications must handle address data from foreign country. Some
>> applications by their nature can only be used in the locale it was written
>> for because the context is not, has not, and very likely will never exist
>> for any other locale. Preparing for all possibilities is nice but it is
>> certainly not always practical.

> That's what I'm talking about. For what you said, I think you would never
> sold to a foreign customer, never buy from a foreign vendor, and maybe never
> had the opportunity to write an application outside of Richmond, Virginia,
> perhaps (of course this is an exaggeration, please don't take it seriously).
>
> I think this is lack of vision, and excuse me if it sounds offensive, but
> that's not what I intend. Walter argued many times that his strategy is
> oriented to keep flexibility, and I think that surrogates are great at that
> and intellignet key not, for that trans-regional issues, in part.
>
> As I see it, the case for foreign data anticipation (note that what is
> foreign for you is local for me, and that we're talking every day, always,
> so borders are not what it used to be), is easily expandable to a lot of
> other situation of sudden specification changes.

You are right in assuming that most of the applications I work on are not what
you would call traditional business applications. For example, I have designed
system to

(1) measure real-time quality control of a production line.
(2) decode weak signals (with lots of white noise).
(3) simulate catastrophic events and other historic events.
(4) measure the long-term effect of hiring/firing/offering severance packages
to employees on the salary mass.
(5) control access to individual cells in high security jails.
(6) control the actions of a robot.
(7) maximize yield of functions that has several non-linear constraints.
(8) determine the danger level of an hazardous environment.

My experience tells me that sometimes, not always, natural keys are a Good
Thing < bg >. Your experience seems to be restricted to traditional business
applications and tells you otherwise. I assume that there are other developers
out there that are wworking on applications in which the judicious use of
natural keys can have advantages.


>> By the way, I generally agree with Walter on the natural key issue except
>> that I don't use composite keys for my own personal reasons. I have been
>> doing this stuff for over 10 years and none of the natural key selections I
>> have made have have suffered any data change...

> You're lucky. I have way over 10 years also in this business and I've started
> using intelligent keys only, and composites also. I actually had a lot of
> problems with both that could have being avoided with surrogates. Many years
> ago we agreed internally that it was best to use surrogates EVER. We have
> improved a lot since then, and in many situations we are glad we decided to
> do so.
>
> So, my last words on that issue is: It has worked for me. I haven't saw a
> single case that really overturn my idea, and many smart people I know agree
> and gave me even better arguments. A few smart people as you and Walter gave
> me other points of view but I'm not convinced.

I don't think luck was a big factor because we only used natural keys for
tables that contained a field that can be used as a candidate key and whose
values were _very_ unlikely to change. Our definition of _very_ unlikely was
narrow enough that we did use surrogate keys in some tables where others would
have selected natural keys and not have suffered any key changes for the 10
years the system has been in production.

You were burned by intelligent (natural?) and composite keys and they left a
bad taste in your mouth. Your experience tells you, and I agree, that blind
use of intelligent and composite keys are a Bad Thing. However, I do agree
that natual keys do not have their place.

Please note that I use surrogate and natural keys only, not intelligent keys.
See my other reply to you for my understanding of these terms.

Daniel