Hello, Jim.

I think I disagree with you and Walter about the consistency issue.

>To do something exclusively "for consistency" is a poor reason indeed, in my humble opinion.

I think not one of us does anything exclusively "for consistency", but for the advantages that consistency already has.

When you work on a team and things like surrogate keys, hungarian notation (in field names or not, it doesn't matter) help your people to get productive, avoid repetitive mistakes, and ship a better product (as much from the user perspective as for the extensibility and documentation), the consistency IS of great value and every step you can do to keep it is useful.

As Erik stated, many of us rely on surrogate and foreing keys to make easier our code. In most framework that do a good use of them, lots of operations are highly encapsulated and just pure exceptions are handled in instances, so anyone can read it and go to the point.

>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 strongly disagree. My customers pay me to give them the best possible product and support. Period.

Even when we develop something to be interfaced of used by other programmers, they are paying us for the best quality, and in this case, consistency is a very valuable asset, as it helps you transfer knowledge in a much easier way in shorter time.

>I don't think that we are paid to make things easier for ourselves.

I do. It's not really what the customer is paying, but I am more profitable (and finally, a better vendor) if I can make thigs as easier as possible for myself and my team.

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

I don't understand wwhy should your user notice any difference in your front end whether you use surrogate or intelligent keys. Maybe we are debating more than database design here.

See you.