What standard should I follow when naming tables and views?

Question

What standard should I follow when naming tables and views? For instance, is it a good idea to put something like tbl_ at the beginning of table names? Should I designate code/lookup tables in some way like ct_, lut_, or codes_? Are there any other do's/don'ts?

I'm using MS SQL Server and have many databases with many tables so it would be nice to have something we can use as a standard with some supporting rational.

Answer 1

OK, first NEVER put tbl in front of a table's name. It's a table, we already now that. That's called Hungarian Notation, and people stopped doing that 5+ years ago.

Just call the object based on what it is. If a table holds employee data call it "Employee". If it holds information about computers call it "Computer". If it maps computers to employees call it "EmployeeComputer" or "ComputerEmployee" (personally I like "EmployeeComputer" better).

There's no real right naming convention to use (other than to not use Hungarian Notation). As long as the object names make sense that it what is important.

Answer 2

We use schemas (think of them as namespaces in SQL perhaps) for both permissions and grouping. So instead of "tbl" etc we have

• Data.Thing
• Data.ThingHistory
• Data.Stuff

No code goes into the Data schema. No tables live outside the Data schema. This can extended of course to have a Lookup or Staging schema if you wish.

For views we use vw but this was to distinguish them from tables in SQL Server 2000 and it's kinda legacy now

Answer 3

Personally I'm a great fan of the Fanö Bedingung, meaning here that not name is allowed to be the beginning of another valid name.

And second the Hamming distance between two names is better more than one different letter.

Yes that are rule from predigital times, but they make life easier.

And third names must be pronounceable, or you will became mad, when voice recognition becomes true.

Answer 4

I don't know that there is really any "best" naming convention out there, as it really boils down to personal preference and ease of development. My advice is to pick a naming convention and adhere to it. If you wish to separate words with an underscore, do so in all of your database objects. If you wish to use camelCase, do so in all of your database objects.

In my shop we adhere to the following rules:

We separate words with underscores and use all lower-case letters.
Our table names describe what they are: dbo.person, dbo.invoice.
Our many-to-many table names also describe what they are (with the addition of mm to indicate a many to many relationship being mapped: dbo.person_mm_address. Our user-defined stored procedures describe both the object and the action being performed: usp_person_select, usp_address_select_by_city Our views and functions follow the same rules as stored procedures. Our indexes include table, key columns (in order), and an indication of clustered/non-clustered: ix_person_last_name_first_name_nc

Just because this is what we use in my shop, it doesn't mean these rules are right for you. Pick something that you and your development team agree is both useful and easy to develop with, and establish a culture of knowing and using whatever naming convention you decide upon. In our case, this includes code review for any objects created in a database. Over time, the combination of a documented naming convention and peer code review has led to fewer and fewer deviations from convention.

I hope this "non-answer" helps in some way.

Answer 5

I'm content with these since years ago

• table names: small caps and underscores, singular {customer, product}
• table names for many to many relations: tablename1_tablename2: {customer_product}
• views: small caps added v to the end {customerv, productv, product_groupv}
• stored procudures: table name and function {customer_select, customer_insert, customer_delete, customer_update}

if you have a cheap shared hosting package, you'll need to use the project abbreviation in front of all your objects, like for example, database administrators site, da_users, da_questions