Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1112131415

Best Practices for Database Design Expand / Collapse
Author
Message
Posted Sunday, June 22, 2008 8:39 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC 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
Posted Sunday, June 22, 2008 8:59 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:47 PM
Points: 35,959, Visits: 30,252
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."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #521411
Posted Monday, June 23, 2008 8:08 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-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
Posted Friday, June 27, 2008 7:08 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, February 12, 2014 9:22 AM
Points: 201, Visits: 402

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
Posted Friday, June 27, 2008 7:09 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, February 12, 2014 9:22 AM
Points: 201, Visits: 402
Hey Jeff -- a good thread is a good thread. ;)

--Paul Hunter
Post #525402
Posted Saturday, June 28, 2008 11:52 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:47 PM
Points: 35,959, Visits: 30,252
paulhunter (6/27/2008)
Hey Jeff -- a good thread is a good thread. ;)


No doubt about that... :)


--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."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #525522
« Prev Topic | Next Topic »

Add to briefcase «««1112131415

Permissions Expand / Collapse