views:

53

answers:

1

In C# I always use PascalCase for properties (best practice, right?), for databases i always use lowercase for tables and columnnames (best practice, right?)

When I generate classes from tables using entity framework, i get lowercase property names in C#, so I manually refactor the case in C#.

I wondered, is it best practice to use PascalCase table names and column names in the database, when the purpose of the database is to provide backing for a C# application that uses entity framework ?

+2  A: 

You're right about Pascal Casing being right for C# properties, however I would disagree with your comment about lower casing being best practise for databases. I always thought Pascal casing was the best practise in table names and column structure. (That's what I was told by a DBA at an old job anyway and it seems to be consistent with everywhere else I've worked.)

Anyway, if your company's coding/development standards say that the database must have lower case names for columns and tables, then you have to do it. You shouldn't write a database specifically for use with Entity Framework. EF is an ORM, not a database, so the database should not care about how it's accessed.

You should design the database, sticking to any rules you have in place, and then make Entity Framework remap those columns to correct property names. It's incredibly easy to do through the Model Editor.

GenericTypeTea
PascalCase is only really viable where the table/column names are case-sensitive - most versions of SQL I have used do not have case-sensitive table/column names. For this reason, it seems to be more common to use a single case, separated by underscores, for SQL names.
Mark Bannister
I agree that it is easy to do with the model editor, but it is also a manual and tedious process. Compared to how easy it is to add an ADO item and have it autogenerate the classes, refactoring the casing is far more time consuming. Which i think is a bit out of proportions.
Skipperkongen
@Mark Bannister - We use Pascal casing within our SQL databases purely for readability. Underscores are an extra, unnecessary character according to our coding standards. But then, every software house is different. Something that applies to one doesn't apply to all, so I do see your point.
GenericTypeTea