Re: Microsoft Access, Double Data Entry and breaking the Normalization rule

On May 30, 2:02 pm, DavidB <j...@xxxxxxxxx> wrote:
All the data is entered into the "tbl_DateE", with the following 5
Key fields: [DtaPartID] (Participant ID), [DtaQstnE] (evaluation
number), [DtaSrvID] (Survey ID), [DtaEntry] (1st versus 2nd entry),
[DtaQstnQ] (Question Number). There is one other field [DtaRspns] that
contains the participant actual response.

I have an aside question here. Noting the table structure above, why
is it that people abbreviate field name to the point of
nonrecognition? Take for example the field DtaSrvID in this table.
Why not name it DataSurveyID which is (I ass-u-me) the data element it
contains? It will make going back into the code at a lated point MUCH
easier. I code and support a large number of databases. Some of them
written by other folks who use these abbreviated naming conventions.
There are many times it takes me a lot of time to figure out what the
data elements even are because of this. The fact that the person
asking the original question had to add an explanation of each field
next to the field name kind of makes my point. Is there any actual
advantage to using the abbreviated field names or is it just a throw
back to the early days of geekdom where space was limited akin to the
2 digit year? (Paul, I am not kicking your cat by asking this. Just
something that has been bugging me for a while and figured I would
ask.)

Hi DavidB,
Interesting question. For me, it's always finding a balance between
having a variable name that is short and easy to type (for queries and
VBA code) and having one that is too short to be recognizable. With
something like DtaSrvID, I figure that by capitalizing every segment,
it's generally pretty recognizable. (I added clarification, just in
case). I also like have the first part of the variable refer to the
table, thus Dta references the fact that this variable comes from the
Data table.
Paul

.