Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Response Guidelines
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00457550
Message ID:
00458719
Views:
32
Pardon my nose, please, but I couldn't pass on this...
Snip
>>Well, what about the case of invoice numbers ??? Are you consistent and add a surrogate key, even though a autonumber invoicenumber would do ? I'm not, because the surrogate key would add no benefit to the current scheme.
>
>Yes, I would add a surrogate key. The benefit to the current scheme is that I can treat all my tables in a consistent manner. The all have surrogate keys, each is named TableName + "ID". My argument is still the same: consistensy. I'll gladly trade a little overhead, and surrogate keys are very little overhead, for consistency.
>
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".

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.

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

JimN
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform