In message <es9jqh+5k9a@xxxxxxxxxxx>, caprecerevisi2005 <wolfear@xxxxxxxxxxxxx> writes >I have to disagree in that I find nothing wrong with the naming of >variables the same as a field name and that "ratesheetID" will prove >much less confusing in the long run than simply "usrID". >What happens should there ever be a "usr_foo" table? >You then potentially have 2 "usrID" floating around instead of >"ratesheetID" and "fooID". That was my suggestion, and if all the tables are going to be called usr_xxx (why would you do that??) then it would probably be rtsID and fooID. You KNOW that it is the ID of a ratesheet, because it is in the ratesheet table, so why add that into the name? And more letters = more spelling mistakes. >Conversely, putting a bit of forethought in the basic database design >will go a long way towards avoiding the potential for confusion also. And THAT was my point. I am working for a client who has 3 databases, one has only one table in it - only because an earlier programmer put it there early on in development - and the others have no naming pattern at all, so each time I want to access a field, I have to look it up on the list to see what it is called. -- Pete Clark Sunny Andalucia http://www.hotcosta.com/comm_1.htm
