SQL Field Names: Spaces or Naming Convention?

[HillBilly]

Most of us have been taught to use a conjoined naming convention such as
FirstName, LastName but the real world and a well done User Interface
demands the use of explicit grammatical naming expressions which uses
spaces; First Name, Last Name and so on. Now I understand the conjoined
convention was established in the "old days" when spaces were not supported
by database software but hey, its supposed to be 2008 and SQL Server
supports explicit naming of fields which includes support for spaces.

So, from a developer's perspective; which is your preference and where do
you think you find it okay to deviate from typical conjoined naming
convention?

// Scenario...

We have a table which contains Membership Profile data. We want to generate
a Profile Manager dynamically from the table schema and its data hence the
text property for labels or Link Buttons used on the UI of a page should be
populated with the name of the SQL table's field name --else-- we would have
to utilize a helper class which uses a collection of grammatically
expressive names while the SQL table remained named using conjoined
conventional names. Obviously the synchronization and maintenance gets to be
a problem real quick.

What has the best practice for this scenario? I am in process of using a
ListView control for the first time and this may be an opportunity to try to
automate the text properties of labels and Link Buttons by using the field
names from the SQL table but I don't want the UI on the page to read
FirstName, LastName when it should read First Name and Last Name. eh?

 

[William Vaughn \(MVP\)]

While imbedded spaces is widely supported in Access, once you get into SQL
Server and other DBMS systems you'll often find that they are a nightmare to
managed. Each column reference must be bracketed [Last Name] (at least). I,
for one, encourage CamelCase field notation and discuss a couple of
alternatives. Because you can assign an Extended Property to any object in
SQL Server, it might make sense to define a "Description" property to your
columns as well as other metadata. Consider that some tools like Reporting
Services report wizards automatically deal with CamelCase column names as
does some Visual Studio tools (IIRC--they pull features all the time). Yes,
it's a pain, but there are solutions.

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________