 |
|
SQL Server Tips by Burleson |
The Number One Performance
Myth
Whether it’s in the realm of database technology or any other
discipline, some maxims are circulated in hushed tones so much that
they are taken literally as fact and never questioned, especially
when supposed experts mouth the words. Such is the case with the
following database performance myth:
“Eighty percent of a database’s
overall performance is derived from the code that is written
against it.”
This is a complete untruth, or at the very
least, an overestimation of the impact that properly written SQL
code has against a running physical database. Good coding practices
definitely count, often heavily, toward the success of any database
application; however, to state affirmatively that they make a
contribution of over two-thirds is a stretch.
The reason this cannot pass the reality test is that it is stated
independently of what good or bad code can do in the face of poor
physical design. The performance problem example presented earlier
in this chapter is a shining example of how wrong this adage is.
The physical design constrains all code, good or bad, and has the
capability to turn even the best written SQL into virtual molasses.
After all, how can an SQL developer obtain unique key index access
unless the physical index has been created and is in place? How can
a database coder scan only the parts of a table that they need
unless that table has been partitioned (SQL Server 2005 and above)
to accommodate such a request? Only when a solid physical design is
put in place that truly fits the application can SQL code really
take off and make for impressive response times. But, good design
comes first.
The above book excerpt is from:
High-Performance SQL Server DBA
Tuning & Optimization Secrets
ISBN:
0-9761573-6-5
Robin Schumacher
http://www.rampant-books.com/book_2005_2_sql_server_dba.htm |
