>>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
>
>IMHO long names are fairly well. However, you are saying "preferences", then looks like there is a problem in design. I wouldn't expect you to have 'require_labor_entry_when_closing_order' as a field name but rather as a value in "Property" name column. You could save your properties as:
>
>Property, Value ( some more additional fields if you want like Section, ValueType ...).
>
>Otherwise having many preferences might mean to go over allowed column count.

We use similar design with out Settings table. Property Name, Property Value and Property Type. It's a little bit tricky to work with, but allows many different types of properties saved.