Hello, Walter.

>>I just can't advise anyone on something that I don't believe in.
>
>This confirms, my observations, that the choice between intelligent (or natural) and sorrugate keys is more of a religion than one of a science.
>
>It seems that because your 'believe' you have not opened your mind for some very good reasons daniel has given here.

No, no. Anyone who knows me can tell you that I'm everything but religious. I believe or not just in FACTS. For me, as I think I stated clearly here lots of times, are FACTS that maks my belief. I should say the same about your position, but of course I don't think so.

I think that no one that went trough this discussion deserves to be called "close minded".

>Two very good points:
>1. If having a table with many (x) foreign keys, for reporting (when only adressing the value of those meaningfull keys) you'll have to include x joins to accomplish the same report with surrogate keys. This means:
>A. Performance could be terrrible as the number of x goes up.
>B. The table is far more readable when either debugging it, or presenting it to endusers in any way.
>
>2. When using static (single attribute) natural keys (like in the superbowl example) I see no problems arising here.

1. I said many times that -for me-, even on this extreme cases where for some use (a single report perhaps), the benefits of using surrogates could easily offset any of the troubles.

>I get the impression, you're also in the 'consistency' camp, are doing things mainly for the sake of consistency, not for the sake what might be best in your situation.

I am in the consistency camp -and not, I don't follow it religiously. You stated that you have something against consistency. I just don't. For me consistency is a goal trough design, coding, user interfase, and what the hell, even life. That doesn't mean to get stuck with a method or tool when you dicover it wrong. But as soon as some practise proves you helpful and its benefits when used consistently are more that some inconvinience that can cause you, I prefer it. It's a matter of balance for me. Of course, balance makes that sometimes you need to deviate from your consistent method because it doesn't pays off, I recognize it. Just don't think is the case for surrogates.


>Your experience might tell you, you've never encountered problems with using surrogate keys. My experience say's I have enjoyed using natural and intelligent keys for the last few years.

As I said, I can't counter YOUR experience. And I don't pretend you to advise on mine, neither.

>Why ? Because, whenever someone asked me to retrieve some information from the database that was not available from within the program, I often could do this with a single table action like:
>
>USE table
>BROWSE FOR ...
>Or
>SELECT * FROM OnlyOneTable WHERE ....
>
>without having to set relations or use joins to see the meaningfull side of surrogate keys. When something went wrong, I found it helpfull to see all kinds of natural keys to determine what went wrong. I could safely say that it rescued my butt more than once. I certainly think this task is a whole lot more difficult if I used surrogates everywhere, esspecially when doing such ad-hoc queries trough a WAN on a vfp table.

As we (I refer to me and my company) started to propagate the use of surrogates, this was an inconvinience because some people where no very technical and saw joining as something a bit complex. Today is just the same for us. Having enjoyed the many benefits, anybody cares about having to type a little more. And never felt that performance was an issue (except in those cases where something was actually not optimized and need to be fixed anyway).

>I think, we both have two differente relgions, and as always with 'religions' it's hard, if not impossible to convince the other.

I think we don't have religions, but different viewpoints. You are VERY analitycal, which is very good, even if at some point someone can think that you overcomplicate thinks.

>We'll have to respect eachothers 'opinion' and as time passes by we will see both are points to have merit.

Of course. It has being my point since the begining.

I'm glad we finally reached an agreement in that.