>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

Now, that there is no short limit into a field name, when required, yes, you may use that route. I avoid special characters. All field names I have are letters only. I avoid plural. If it is a table or a field name, there is no "s". Everything is plural in the concept of a database. So, there isn't really a need to indicate that. So, if you adopt such convention, when you go in the code, it can now be assumed that there is no "s", as to know should I put one or not.

So, in my case, I have fields like this:

FirstName
LastName
ExpirationDate
RenewalDate

That is about it and very simple. I would try to remain, however, within 20-30 characters at most, as, as mentioned, it could become very long. But, for some exceptions, you could be better to use 35-40 characters. It just depends on what you want to express.