SNIPPAGE
>
>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.
>
Well clearly the folks who opt to extend Hungarian to even the field names have a different view of "consistency" than you and I do. We seem to be "consistent" on this issue, but the others think you and I aren't.

>And what are your arguments against using Hungarian notation in code?
>
I really don't want or need to go there. Suffice to say that I have a (near) genetic abhorrance to it. Period.

SNIPPAGE
>
>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.
>
Again a question of definition and how far one takes it. My view is that it *is* consistent to think each key out carefully and then choose the best option for the job at hand, the user's interests ALWAYS winning in the case of a conflict.

>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.
>
Well I agree 100%, but not to the depth (apparently) that you do. I truly appreciate (with a capital "A") any system that I have to mess with where the programmer has been *consistent*. But it doesn't have to be consistent with *MY* way of doing thing - just consistent throughout. That's what makes my life easier when I tackle someone else's code. If s/he happens to think just like me too then that's truly a bonus. After all, programming is more creativity than it is process, and most people do not "create" in exactly the same way.

>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.
>
Still seems to me that you have to look it up your way, if only to be sure that it's there. Once there it really isn't that hard to take note of the type too (though a guess at Char. would probably serve 90%+ of the time).
And you have a "mix" because you've applied careful thought and reasoning. You haven't blindly made a surrogate key just because *you* like it better. Careful thought and reasoning could, you know, still result in all surrogate keys in an application.

>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?
>
And how does Walter's way prevent it from also being CustomerID? And does the next guy who has the privilege of enhancing your system know this already?

>When a PK changes in Walter's system, who writes that cascade trigger? My system doesn't need it.
>
I suspect that Walter's approach would also choose for a surrogate key when the likelihood of the 'natural' PK changing was high. That's what careful thought and reasoning buys you.

>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.
>
As I said earlier, so would/do I (yes, even their *consistent* use of Hungarian is helpful).

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

This, like the Hungarian thing, is not an argument that one wins or loses. We all have differing preferences and viewpoints, and thank heaven for that! I happen to enjoy the internal struggle that choosing any key causes, believing that my applications, my users and the programmers who later work with the application are better off for it in the end. I'm sure you feel the same way about your work. A damned problem, this "creativity" thing!

Cheers,

JimN