@element[0] said:
I couldn't find anything in the search on this topic but my apologies if it's been posted before.
I recently had to do some bug fixing/feature requests for a .net + SQL Server application written by a contractor at another company who had since gone overseas. Thankfully the code was quite neat, well commented and easy to understand (unlike most maintenance jobs). There was one thing i found strange though about his database naming conventions, all the tables and field names had spaces in them ie. "Customer Request Information" which has a field like "Date Of Request". I usually try to avoid spaces in my field names and table names and use camel casing for tables and usually _ for stored procs. I can see where his approach has merit though, it is more readable and, this is slightly dodgey, but if you were doing some kind of dynamic data binding the db field name would be the label you would actually want for that information at the presentation layer. The only real annoyance i can see is having to put everything in [] but then again in the production code all names should probably be wrapped in [] anyway.
I was just wondering what the general feeling was with database naming conventions? I'm wondering if i should switch my naming conventions to that style..
The important thing to remember is that you name your tables and columns appropriately. This means that if the table you're working with contains customers, your table is named Customer. Not Customers, tblCustomer, or Customer_Data. Your column names should similarly express what's in the column. Since you're working with SQL Server, take advantage of the environment's expressiveness by using those spaces. After all, as you pointed out, production code should enclose table names in square brackets, and as AmmoQ suggested, your table names should be properly qualified. IIRC, SQL Server will otherwise assume you specifically want it to search the available schemas for the table you want, rather than specifically referencing the particular schema you're using - probably dbo, if the author left things fairly default. Of course, maybe you really do mean that, in which case it's just a matter of knowing what the difference is and why you would choose one rather than the other.
I recommend getting comfortable with spaces and square brackets because many of the concerns others have posted are along the lines of "but what if you want to port it to x?". As AmmoQ again pointed out, some RDBMSs require globally unique table names and a max of 8 characters. Just how backward compatible do you want to get? Do you want to start naming all your tables A, B, C, ..., you know, just in case a hypothetical future or past platform only supports or will support single character, case senstive, alpha only, globally unique tables? What if someone is actually stupid enough to tell you to port the system to that platform? And what if rather than .net you have to port your codebase to COBOL? Better watch those variable names!