RSS 2.0
 Friday, January 19, 2007

Thanks for attending my talk last night and letting me share my SQL Server 2005 Worst Practices. I hope I didn't embarass anyone too badly by highlighting your practice in my talk!

Here are the slides, script, and sample project from last night's talk.

Also, a small correction: MyGeneration's site is www.mygenerationsoftware.com

Friday, January 19, 2007 8:45:32 AM (Mountain Standard Time, UTC-07:00)  #    Comments [1] -
SQL Server
Monday, January 22, 2007 10:52:59 AM (Mountain Standard Time, UTC-07:00)
Interesting stuff in your presentation.

Though I am primarily an Oracle DBA, and something of a newby with SQL Server, some things don't change regardless of database.

Use of cursors may be a good example. When you recommend avoiding them if possible, I am assuming that refers to processing rows in a loop, rather than a blanket condemnation of cursors.

Set operations are nearly always more effecient, as stated in your presentation.

One thing that was mentioned was whether a table for customers should be named CUSTOMER or CUSTOMERS.

Here's some food for thought on that matter. Several years ago Richard Barker wrote a series of books on Data Modeling. He made the point that when defining an Entity it should be singular, as you are referring to abstract representation of a unit of data that you are trying to model.

When translating the CUSTOMER entity to a table, it would be CUSTOMERS, as the table is the instantiantion of the CUSTOMER entity and as such contains many instantiations of CUSTOMER.

One point that I take strong exception to was in regards to over-normalization. You made it a point to say that 'over' normalization was detrimental to peformance.

Not having heard your presentation I do not know what points you may have made to backup this statement.

This statement that normalizing a database bad for performance is not really true.

This statement is often made in the context of a SELECT statement. Sure, a de-normalized table will faster than a normalized table for a single SELECT statement.

But what about INSERT,DELETE and UPDATE statements?
The convuluted code necessary to perform DML on denormalized tables will usually perform much worse than DML SQL that is used on normalized tables.

The statement made in your presentaton about the use of cursors is especially apropros here, as denormalized tables often require procedural code to perform DML.

An even bigger problem with denormalized tables is that they are an invitation to incorrect data.

If you don't mind reading a paper that is based on Oracle examples, consider "Normalize for Performance" at http://jaredstill.com/articles.html

Name
E-mail
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):

Archive
<August 2008>
SunMonTueWedThuFriSat
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2008
Richard Hundhausen
Sign In
Statistics
Total Posts: 690
This Year: 26
This Month: 0
This Week: 0
Comments: 479
Themes
Pick a theme:
All Content © 2008, Richard Hundhausen
DasBlog theme 'Business' created by Christoph De Baene (delarou)