>HUGE snip
>... surrogate keys just for consistency.
>
>At one time FPA published an article with a routine to make TAGs out of every field in a table. That way you could be consistent as well as always have max. Rushmore effect. Sounds odd now, eh?
>
>At one time FPA published several articles propounding that we ALWAYS have a TAG on Deleted() in EVERY TABLE to get the max. Rushmore effect. And all of my observations *at the time* supported the stand. Just over a year ago the opposite was stated in an excellent article that was published about 6 weeks after Walter (the very same one) had questioned the effectiveness of a TAG on Deleted() *in the general case*. He was crucified for that one (somewhat like this time, though more benignly this time) even after the FPA article appeared. And many here have been caught still advocating Deleted() TAGs on avery table.
>
>And there is the ever-present discussion on "to Hungarian or to not Hungarian", where countless advocate TO Hungarian for a variety of reason but fewer (but nevertheless numerous) argue (practise) to NOT Hungarian. I don't myself any more, now that I can.
>
>To do something exclusively "for consistency" is a poor reason indeed, in my humble opinion. It has gotten us in the past and is certain to do so again. And an example that might serve to show where does consistency "end", consider the argument *for* Hungarian. Does it mean that field names too should adhere to Hungarian for the sake of consistency??? I think you'll find that even amongst the countless who practise Hungarian they are split on this issue. My opinion is that even when I did use Hungarian I did *not* use it for field names because Hungarian was for *my* benefit and in field names I was actually hurting the users. But I know there are many who insist on using it in field names too "for consistency".

Your argument here against consistency is, in a word, inconsistent. You are comparing apples and oranges in regard to Hungarian notation in code and in field names. The two are really separate matters. What I want is that if you use Hungarian notation in your code, use it throughout your code, and if you use it in your field names, use it in all your field names. This is consistent.

And what are your arguments against using Hungarian notation in code?

>I feel that it is just as *consistent* to take each decision (on keys) on a case-by-case basis. It seems to me that it is that kind of thought that we are paid for in the first place! I don't think that we are paid to make things easier for ourselves. Especially when they can easily get in the way of a users understanding of the system as well as impede a programmer designated to revise the system in question. Our users should always be primary in our minds and if a surrogate key is going to cloud his/her impression of how the system opertes and what it takes to get at certain things, then they should be avoided. If they give the user the flexibility that they need (like being able to change a surname without doing hand-stands) then they should be used for that purpose. But to ALWAYS use them or the NEVER use them is simply wrong, and I don't think that Walter has said nothing more nor less than that.

No, what Walter has argued for is a mixed system. As a programmer, I don't like mixed systems. I do not like taking over a system where Programmer Bob loved global variables, while Programmer Tom used a mix of globals and privates, and Programmer Pete used Hungarian notation, complete with LOCALs.

Being able to create a system where:

1. All the Primary Keys are surrogate keys.
2. All all integers
3. All are named TableName + "ID"

doesn't just make things easier for me, it makes it easier for anyone else who has to work on the system. That is what I get paid for. We have all heard the argument that the major cost of a system is maintenence. There is nothing that saves me more time then when I work on a system that is consistent.

In Walter's system, you have a mix of primary keys: intelligent and surrogate. So when I, or any other developer wants to know that the PK is for the Invoice table, I have to look it up. Not only the name, but the type.

When I write the middle-tier for this system, how do I handle retrieving a Customer record. With my system, I already know that the PK is CustomerID. With Walter's?

When a PK changes in Walter's system, who writes that cascade trigger? My system doesn't need it.

And how does using surrogate keys cloud the issue for the users?

And as far as impeding the developer, I would love to take over a system where there was that much consistency, just as I appreciate someone who uses Hungarian notation in their code.

>So count me as one "produced" on the Walter side of things.