Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 Site Related Forums
 Article Discussion
 Article: Database object naming conventions for SQL Server

Author  Topic 

AskSQLTeam
Ask SQLTeam Question

0 Posts

Posted - 2001-05-20 : 22:48:51
Narayana Vyas Kondreddi submitted "Database object naming conventions for SQL Server: This page proposes a database naming convention for SQL Server, which insists on natural and readable names."

Article Link.

RocketScientist
Official SQLTeam Chef

85 Posts

Posted - 2003-07-21 : 15:23:05
I've got to disagree with some of the article.

Table names should always be singular. Because (1) I said so and (2) because you end up with things like the article's example: TerritoriesManagers. Yick. Asthetically not pleasing. You're also relying on everyone to remember the singular/plural forms for everything (Quick, what's the plural for stadium? Media?) (Answer: Stadia, and Media is already plural, the singluar is Medium).

There really are only 3 rules to remember on object naming: Consistency, consistency, and consistency. If you're going to abbreviate something, always abbreviate it the same way (I usually just don't ever abbreviate anything). Don't abbreviate AccountPayable as ACCPAY once and AcctPayb the second time. Always abbreviate the same. Always name your key fields after the table (AccountPayableID), and not some off-the-wall abbreviation. If you maintain consistency you'll tend to guess what object names are more often than not.

I tend to agree with the v_ notation for views, however, most of the time I use a view it's for backward compatibility (we need to change the table structure, but don't have time to change all the old applications) so I end up naming the view the same as the old table, and building the new table with a new (correct) name.



Go to Top of Page

OOPLord
Starting Member

1 Post

Posted - 2005-10-31 : 15:36:14
I absolutely disagree with the premise that tables should be singular and here's why;

1. A table is not a single entity, it holds a group of entities.
2. A row in a table is a representation of a single entity
a. A row is a customer
b. The table that holds them holds customers, not customer.
3. The name of a thing should describe what it is.

If we expand the name out to what is actually being said it becomes clear.

A table that holds customer -or- A table that holds customers

Which is (a) gramatically correct, and (b) makes sense?

Go to Top of Page

ericis_com
Starting Member

2 Posts

Posted - 2006-05-10 : 15:19:20
I have personally struggled with this for a long time, but recent enlightenment has given me a new perspective and personal standard.

[url=http://www.ericis.com/Posts/default.aspx?id=184]Read my blog post for details.[/url]

Eric Swanson
http://www.ericis.com/
Go to Top of Page

ericis_com
Starting Member

2 Posts

Posted - 2006-05-10 : 15:19:22
I have personally struggled with this for a long time, but recent enlightenment has given me a new perspective and personal standard.

[url=http://www.ericis.com/Posts/default.aspx?id=184]Read my blog post for details.[/url]

Eric Swanson
http://www.ericis.com/
Go to Top of Page

fxtrader
Starting Member

1 Post

Posted - 2006-10-09 : 17:58:34
quote:
Originally posted by RocketScientist

I've got to disagree with some of the article.

Table names should always be singular. Because (1) I said so and (2) because you end up with things like the article's example: TerritoriesManagers. Yick. Asthetically not pleasing.



I'm with you on this. The idea that the row of a table represents an entity - and that having multiple rows implies the table name should be plural - is not really correct. The table definition taken as a whole is a logical representation of an abstract entity, for example 'customer'. The rows in the table aren't the abstraction (object) but the concept of 'customer' is the abstraction. The rows in the table really have nothing to do with the abstraction. The entity we're representing is not 'Customers' but 'customer'. Put another way, whether I have one customer - and am out of business :( or many customers, the abstraction is still 'customer' and singular. And the abstraction is what's important for oo programming.

Therefore, in my opinion, the singular word is more appropriate to affix as the title of our logical representation of the abstraction - the table. In this way, we've taken a nice step toward our oo system design.

This aside, what Rocketscientist said about concatenating plural table names is right on. It is not natural and frankly, I've been programming db's a long time and can't recall a published book showing it that way or a large database structure with that naming convention being chosen.
Go to Top of Page
   

- Advertisement -