.NET/SQL naming conventions?

[Guest]

There seems to be a trend toward the SQL naming convention advocated by Joe
Celko that replaces Pascal casing of column names with underscores. For
instance rather than naming a column SaleDate the trend seems to be to use
the name sale_date instead. I much prefer this convention, but in the .NET
world the preferences seems to remain Pascal casing, at least for public
properties.

So the question is, do you standardize the naming convention across both,
translate the names at some point, or do you not worry about it?

For instance, I’ve started using techniques such as looping through public
properties and stored procedure parameter names and matching them by name to
set the value of one from the other rather than hard-coding the population
for each database call.

Foreach column name
Find the public property with the same name
Set the value of one to the other

Obviously I could use a method that translated names between the data layer
in .NET to the database, and that’s where I would choose to put it if
translation is the solution I land on, but I’d rather not.

Foreach column name
Replace _letter with upper case letter
Find the public property with the same name
Set the value of one to the other

Assuming I can limit data access to stored procedures only I could also
translate the names there, but that makes the database inconsistent.

SELECT sale_date AS SaleDate
FROM …

Can anyone point me to an existing intelligent discussion of this, or tell
me what you are doing and preferably why?

 

[Frans Bouma [C# MVP]]

There seems to be a trend toward the SQL naming convention advocated
by Joe Celko that replaces Pascal casing of column names with
underscores. For instance rather than naming a column SaleDate the
trend seems to be to use the name sale_date instead. I much prefer
this convention, but in the .NET world the preferences seems to
remain Pascal casing, at least for public properties.

Using underscores is needed when you're working with databases who
capitalize every name entered without "". So on oracle for example, if
you create a field called SalDate it will become SALDATE, it only will
become SalDate if you create it as "SalDate" and also refer to it as
"SalDate", thus with the quotes.

Using underscores then makes it easier to port schemas between
database systems.

So the question is, do you standardize the naming convention across
both, translate the names at some point, or do you not worry about it?

depends on what you use to access the db. IMHO the data-access
technology you're using should make the conversion between any class
field and the db field it's mapped on/related with/represents/whatever
you want to call it.

For example, if the db schema properly uses underscores it's very easy
to reproduce that name as pascal casing (and if you don't want to store
mapping info, you could even go the other way).

I'd go for the naming standard which works best for the language and
environment it's used for. So what works best in C# isn't necessarily
the best for SQL in some RDBMS. What I wouldn't do is prefix/suffix
table/view/field names if it's not necessary.

Frans

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------