>>Hi,
>>
>>Currently my application stores all preferences in several XML files. I am working on converting this approach to storing the preferences in a SQL Server table. The table name will be Preferences. In the XML files, the tag names usually correspond to the preference (for easy reading). For example, it could be 'require_labor_entry_when_closing_order'. I am thinking of replicating this XML tag names into the field/column names in the SQL Server. So the field in the SQL server table will be 'require_labor_entry_when_closing_order' type: Char(1).
>>
>>Is having these long field/column names in SQL Server a bad practice? TIA
>
>Not even the small technical reason of the somewhat latedrafted addition of the vfp dbc.
>
>But names that long will require more time just to human read/parse - even if smart editors cut down on the typing amount.
>And reading will happen often, perhaps such long names will slow you - they do for my typical processing
>
>Some of my rules of thumb are:
>try to normalize AND shorten by introducing codes for often used parts (i8 for long_integer, req for require ?)
>leave out parts with no real new info (perhaps "entry" in example)
>if less often used, my resistance to long names is small, as impact is minimal, but if used often/regularly, I try to shorten/invent codes
>keeping in line with curent naming trends I'd use perhaps "onClose"
>
>it might be that such long names will skew your POV: this is a validation, which might be part of "onClose" but perhaps used by other
>events as well - events should call methods, which are sometimes just a few calls to more atomic methods. But here perhaps my imagination is just runing wild ;-)

Thank you very much for your input.