views:

46

answers:

2

I need to create database for SQL Server, what kind of naming convention I sohuld use?

1) Table names could be : customer, Customer, CUSTOMER

2) Field names could be : customer_id, CustomerId, CustomerID, CUSTOMER_ID, customerid, CUSTOMERID and so on...

Is there any official suggestion for naming conventions or what is msot common way to name tables and fields?

+2  A: 

There are a lot of different and differing standards - pick the one that makes most sense to you and then stick to it - that's the most important part. Have a standard and live up to it!

Things to consider are:

  • naming the tables - singular (Customer) vs. plural (Customers)
  • naming the tables - with or without prefix, and if with: what prefix? (Customer vs. tblCustomer vs. T_Customer vs. something else entirely)
  • naming of columns - any defaults? E.g. ID for the primary key? Or CustomerID?

  • naming of other database objects like views (CustomerView vs. vwCustomers), stored procedures (just be sure to avoid sp_ as your prefix! Reserved by Microsoft), user-defined functions (GetData vs. fnGetData vs. func_GetData)

There's no "official best practice" on this - different standards suggestions have their merits, but you're basically free in choosing what you want to use for your own company / your own doings.

Just google or bing for "sql server naming conventions" and you'll find a gazillion of different standards. Pick the one you're most comfortable with, or come up with your own.

marc_s
A: 

Personally, i tend to TitleCase and pluralize table names. Make the table names single words as much as possible, but if you can't, i've seen TableName, [Table Name], and Table_Name out there, in that order of frequency. The spaced version is kinda asking for trouble, IMO, but if you use stored procs, it shouldn't cause too much.

Aside from that, in SQL Server, it seems common to capitalize field names as well. Avoid having the table name in the field name -- Customers.CustomerID is redundant. And yes, i said ID, not Id. That's a personal preference of mine, but it doesn't really matter either way -- SQL Server doesn't care about case in most any case i can think of.

cHao