Best Practices for Database Design

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss Content Posted by J.D. Gonzalez » Best Practices for Database Design

146 posts, Page 15 of 15

«««11 12 13 14 15

Best Practices for Database Design

Rate Topic

Display Mode

Topic Options

Author

Message

sjsubscribe

Posted Sunday, June 22, 2008 8:39 AM

SSC Veteran

Group: General Forum Members
Last Login: Thursday, December 20, 2012 1:03 PM
Points: 265, Visits: 589

paulhunter (6/21/2008)

What a let down. I was expecting an article on good database design practices. Instead we're treated to another diatribe on naming conventions.

I have to agree with Paul Hunter here. Filling the forum with naming convention nonsense keeps real discussions about good database design away. If the author was particular about a certain style, then call it that instead of "good database design". As it stands now, naming conventions as described are neither good, database related, nor well designed. At best it's one solution that probably worked in the author's domain of experience.

As it is we already have enough abstractions for data and application models to layer them anyway we like to suit a particular database design. I don't see any value in imposing yet another spurious layer over already established practices and then call it good database design. Naming conventions have to evolve to suit the problem, not imposed.

Post #521406

Jeff Moden

Posted Sunday, June 22, 2008 8:59 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 9:01 PM
Points: 33,111, Visits: 27,037

Ummm... you guys are getting awfully serious about this... you do realize that the article was written and first posted about 3 years ago, huh? ;)

--Jeff Moden

"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Post #521411

Jeremy Giaco

Posted Monday, June 23, 2008 8:08 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, August 04, 2009 8:25 AM
Points: 159, Visits: 122

Im pretty OCD about the naming conventions that I use, but as long as you have something, it really doesnt matter what they are. Granted, some seem to work better than others for me, but everyone's different. I do feel that it is important to sit down with your respective teams, and nail down a consistent pattern though. It is very nice to walk into a company, read the naming conventions document, and pretty easily guess at how to query the data based on the tables names without digging into each object to identify the columns.

"What was the name of the customer that had orderid 23?...oh,well that would be Select CustomerNm From Customer c Inner Join Order o on c.CustomerId = o.CustomerId Where o.OrderId = 23, of course!" (not that I would format it like a sentence or totally rely on the naming, but you get the idea).

When you get to the point when you have standards for conventions in general, the code pretty well writes itself.

Post #521819

SQLNightOwl

Posted Friday, June 27, 2008 7:08 PM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Sunday, June 16, 2013 3:33 PM
Points: 186, Visits: 394

Jeremy Giaco

It is very nice to walk into a company, read the naming conventions document, and pretty easily guess at how to query the data based on the tables names without digging into each object to identify the columns.

Very well stated Jeremy. I work with a horribly designed database but the naming convention is solid and helps describe the database and it's relationships. The Acct table has a column named MjAcctTypCd (major account type code) and the lookup code table is named MjAcctTyp and is consistent for any code table. The only exception (which is understandable) is that the CurrAcctStausCd comes from the AcctStatus table.

--Paul Hunter

Post #525401