April 30, 2014 at 1:34 pm
Sean Lange (4/30/2014)
Jeremy Brown (4/30/2014)
I find more often than not, people go overboard on naming standards (in my honest and humble opinion).I know I'm probably going to catch a lot of flames for this, but, naming standards that include things like the object type seem senseless to me. Each object in SQL Server has relevant metadata that accurately describes what the object type is (among other things).
I'm more a fan of the simple rule that code should be self-describing. In other words, entity names should accurately represent what entity is being maintained. Executable code should describe the function or behavior performed (more or less).
The "naming standard" should establish the common language usage for these things. For example, functional code that "gets" things from the database should begin with "get". In other words, its an agreement between the developers that we use these common words to describe the action performed. Likewise anything that commits something should be "put" or "write". Choose whatever verbs you like, but make is sensible.
In other words, make it lightweight. Easy enough that can be generate -able in code, but not so difficult that it takes a maintenance programmer a degree in quantum physics to be able to understand.
I agree that the naming standards can go insanely overboard. However your comment about starting the name with the verb is one I disagree with immensely. When you have a system with even a few hundred stored procs it is a PITA when they are all grouped by what they do instead of by what they deal with. It is difficult to find a given stored proc for "get" when there are 200+ that all begin with "get". This is why starting with the object name is helpful. The list is now sorted by object instead of function making it much easier to find the 10-12 procs all dealing with Orders. 😉
+ many
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
May 1, 2014 at 7:14 am
Jack Corbett (4/3/2014)
Andrew,Here's my explanation for pluralization. Because the table doesn't contain a car it contains cars. The row is a car the table is a set of cars. In your Sales Order example my naming would be:
SalesOrders - the table contains multiple sales orders not a single sales order
SalesOrderLines - Non-plural Sales Order because the each of the lines belongs to a single sales order, but the table contains many sales order lines
Naming conventions are always going to be debated, but to paraphrase Grant the important thing isn't what the standard itself is, but that you have and enforce one. In reality I'd name the tables sales_orders and sales_order_lines.
I think the argument against pluralization makes sense. To me, plural entity names encourage bad design habits with regard to selectivity.
An entity should be thought of as a collection of attributes absolutely unique to a singular instance of that entity. Pluralizing creates confusion - does the attribute collection describe multiple entity instances? In other words, does a single row represent a collection or a single instance?
It may sound like splitting hairs but after working with bad design leading to performance problems caused over a long lifespan for an important database, it's an important distinction.
May 3, 2014 at 5:13 pm
Jeremy Brown (5/1/2014)
Jack Corbett (4/3/2014)
Andrew,Here's my explanation for pluralization. Because the table doesn't contain a car it contains cars. The row is a car the table is a set of cars. In your Sales Order example my naming would be:
SalesOrders - the table contains multiple sales orders not a single sales order
SalesOrderLines - Non-plural Sales Order because the each of the lines belongs to a single sales order, but the table contains many sales order lines
Naming conventions are always going to be debated, but to paraphrase Grant the important thing isn't what the standard itself is, but that you have and enforce one. In reality I'd name the tables sales_orders and sales_order_lines.
I think the argument against pluralization makes sense. To me, plural entity names encourage bad design habits with regard to selectivity.
An entity should be thought of as a collection of attributes absolutely unique to a singular instance of that entity. Pluralizing creates confusion - does the attribute collection describe multiple entity instances? In other words, does a single row represent a collection or a single instance?
It may sound like splitting hairs but after working with bad design leading to performance problems caused over a long lifespan for an important database, it's an important distinction.
Other than I'd use Set, rather than entity "An entity should be thought of as a collection of attributes absolutely unique to a singular instance of that entity" - thank you, this sums up my view on the subject better than I've managed until now. If you have a Set that is things that are red, the name of the set to which it belongs is Red, NOT Reds. Is it "Hey, have you seen those Red things over there", or "have you seen them Reds over there"? Same with those things that are a car, they have the attributes that make it Car. Not a cars. The union of those things that have the attributes of being Red, and also being a car would be those things that are a red car. Not Reds Cars.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
May 3, 2014 at 11:21 pm
Sean Lange (4/30/2014)
Jeremy Brown (4/30/2014)
Honestly I don't feel as strongly one way or another. Fine, you want the object name first, go for it. You want the behavior first, fine by me. Its all a matter of perspective.That is the basic sentiment of this entire thread. Everybody, and every shop, has their own opinion. We all agree that no matter what you choose the MOST important thing is to be consistent. Most of us can, have and will work with established conventions as long as they are consistent.
Heh... even if you get used to something, consistently bad is still bad. 😛 For the record, "tbl'ing" and pluralization of entities are two of the things that I avoid in any new database and will sometimes try to correct in existing databases.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2014 at 5:11 am
There's only one absolute No-Go for me due to the technical side effects it can have: never ever prefix a stored procedure sp_ !
The other "strong" standard is not to prefix a table, a view, a sproc or a variable with tbl, v, usp or the data type it represents.
We did it in a previous project and after a few years now we have physical tables named vSomething, functions named uspSomething a.s.o.
Rather confusing...
We've had a discussion about enforcing pluralism, but we decided to name the tables to reflect what a single row represents.
So we have tables named Order, OrderDetail...
Regarding underscores we decided to use it if the names references an upper case abbreviation, e.g. ISO_Standard that would otherwise look not as intuitive (ISOStandard).
Naming standards are a classic example of "it depends" 😀
May 4, 2014 at 7:48 pm
andrew gothard (5/3/2014)
Jeremy Brown (5/1/2014)
Jack Corbett (4/3/2014)
Andrew,Here's my explanation for pluralization. Because the table doesn't contain a car it contains cars. The row is a car the table is a set of cars. In your Sales Order example my naming would be:
SalesOrders - the table contains multiple sales orders not a single sales order
SalesOrderLines - Non-plural Sales Order because the each of the lines belongs to a single sales order, but the table contains many sales order lines
Naming conventions are always going to be debated, but to paraphrase Grant the important thing isn't what the standard itself is, but that you have and enforce one. In reality I'd name the tables sales_orders and sales_order_lines.
I think the argument against pluralization makes sense. To me, plural entity names encourage bad design habits with regard to selectivity.
An entity should be thought of as a collection of attributes absolutely unique to a singular instance of that entity. Pluralizing creates confusion - does the attribute collection describe multiple entity instances? In other words, does a single row represent a collection or a single instance?
It may sound like splitting hairs but after working with bad design leading to performance problems caused over a long lifespan for an important database, it's an important distinction.
Other than I'd use Set, rather than entity "An entity should be thought of as a collection of attributes absolutely unique to a singular instance of that entity" - thank you, this sums up my view on the subject better than I've managed until now. If you have a Set that is things that are red, the name of the set to which it belongs is Red, NOT Reds. Is it "Hey, have you seen those Red things over there", or "have you seen them Reds over there"? Same with those things that are a car, they have the attributes that make it Car. Not a cars. The union of those things that have the attributes of being Red, and also being a car would be those things that are a red car. Not Reds Cars.
Thank you. I completely agree with this. It's not necessarily a naming standard - it's a "making sense" standard.
I think more to the point is that companies today have major turnover. The database left behind usually has poor or nonexistent documentation. Compound this with confusing noun / plural noun definitions, it's easy to lead a future project down a major rabbit trail. The examples we're providing here are a bit superfluous, but when you're dealing with more complex definitions and nouns, the lines are blurred pretty quickly.
Glad to see I'm not the only one who feels strongly about this. Again, it's not really a naming standard. It's more about enforcing the strictest definition of an entity to avoid confusion.
Viewing 6 posts - 31 through 35 (of 35 total)
You must be logged in to reply to this topic. Login to reply