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

I don't use Hungarian notation in my field names, but I have heard some very good arguments for doing so, including:

1. Avoiding reserved words (more of a problem in SQL Server than VFP)
2. Easier to know the data type

But I am still not using Hungarian notation in my field names for a very good reason: I don't like the way the field names look. < g >

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

I have difficulty understanding your view, but if you do not wish to discuss it, that's fine.

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

Where is the conflict with the user?

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

With surrogate keys, I can guarantee consistency. Every time. With intelligent keys, you cannot. My argument with Walter was that at some point, no matter how much you favor intelligent keys, you are going to use a surrogate.

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

If I document my database and right off the bat say that I cam using surrogate primary keys, they are integers (or possibly ROWGUIDs), and they are always named TableName + "ID", and the developer still looks it up... well, what can I say? If the database is large enough, and they look it up the first 20 times, I bet at some point I am going to save the developer some time an effort. And if they still look it up? Well, these are the type who wonder if anal retentive is hyphenated. < g >

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

No, but in my abstract class, how do I generically code this? Even if Walter can create a consistent naming convention (TableName + "ID"), he cannot guarantee data type and size for his PKs.

The next guy has the privilege of reading my docs, where I say:

1. Every table has a surrogate primary key
2. This is an integer or ROWGUID
3. The name of the PK is TableName + "ID"

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

The more these scenarios are introduced, the stronger the argument for surrogate keys becomes.

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

I am still not seeing how things are clouded for the user.

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

No one wins or loses? Then what is the point of debate < g >. This is like when I play recreational soccer. Even though it is just for fun, I like to point out that both sides still keep score. < g >