- Paperback: 298 pages
- Publisher: O'Reilly Media; 1 edition (September 1, 2008)
- Language: English
- ISBN-10: 0596514972
- ISBN-13: 978-0596514976
- Product Dimensions: 7 x 0.6 x 9.2 inches
- Shipping Weight: 1.1 pounds (View shipping rates and policies)
- Average Customer Review: 8 customer reviews
- Amazon Best Sellers Rank: #2,974,876 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Refactoring SQL Applications 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Customers who viewed this item also viewed
About the Author
Stephane Faroult first discovered relational databases and the SQL language back in 1983. He joined Oracle France in their early days (after a brief spell with IBM and a bout of teaching at the University of Ottawa) and soon developed an interest in performance and tuning topics. After leaving Oracle in 1988, he briefly tried to reform and did a bit of operational research, but after one year, he succumbed again to relational databases. He has been continuously performing database consultancy since then, and founded RoughSea Ltd in 1998.
Pascal L'Hermite has been working with relational databases in OLTP, production and development environments on Oracle Databases for the past 12 years and on Microsoft SQL Server for the past 5 years.
Top customer reviews
The emphasis - in the preface and the excellent Chapter 6 - is that the real gains are usually elsewhere, when you have older code.
I work with a 25 year heritage of fairly well written apps. Many of them have the described situation - a single query that's been broken into two or more parts, with an outer loop and (at least one) inner loop. When server memories were 64K, or 1 Meg, or 4 Meg, and CPU's only came in packages of 1, and disk channels were slow, and networks were slower, this was often the only practical way to get a result.
The interplay changed over the years, but the old code worked. In the past few years, with 64-bit processors, cheap 64-CPU servers, and multi-io disk channels, a wierd thing happened. We found that moving to newer systems and faster hardware made things run SLOWER.
The answer time and again was in those "split loop queries". If we turned them back into one big query - the kind that you couldn't run before, we would see performance improvements of hundreds or thousands of times. In the end, the math proved - on powerful machines, most of the overhead is sending the query, compiling it, and sending it back. If one monster query takes a full second, but every query in the loop takes 1/4 second - if that inner loop runs 1000 times, you lose.
Meantime, that 64-core machine has every CPU working full blast - recompiling the same stupid statement over and over! The problem is, you try to tell this to a developer, they don't beleive you "I didn't change anything in the code".
And that's what this book is about. Changing the code. This book validates what I've been trying to tell my managers and coders; I am grateful to Faoult and L'Hermite for showing I was not making this up myself.
The second reviewer is just reading the wrong book for whatever it is they are trying to do.
This is an essential book for certain people, and is certainly of no interest whatsoever for others. (If you don't own a 1941 Plymouth, the 1941 Plymouth manual isn't much use - otherwise, it's a must).
I've heard the phrase so many times, it doesn't even register on me. Sure the application design is the most important factor in performance, but what do I do about it? Well, "Refactoring SQL Applications" (RSA) is the book I've been waiting for. RSA lays out examples of how application coders tend to think either procedurally or object oriented and how this thinking can completely miss the boat when it comes to writing SQL and interacting with databases.
In RSA, Stephane Faroult, lays out examples of Java code, user defined functions and views and how a coders notions of modular procedural programing and/or object instantiation can undermine database performance from cookie cutter reuse of code to table joins written in Java. If you've ever seen Tom Kyte's "Developer Super Session - The Best Way", then you know the best way is not to do it all and his example is coders doing "count(*)" to find out how many loops to do or how big an array to layout. Tom explains the disasters this can create and how the best way is just to not do the count(*) and how this works by letting the database do the work. Letting the database do the work is explained clearly and with many examples from different perspectives in "Refactoring SQL Applications".
A set of SQL refactoring patterns - like what Martin Fowler offers in his book for oo languages.
I want to know stuff like:
How do i remove duplication in SQL.
How to make the code more readable/clear and decoupled
how do i change the structure of queries without changing the results.
how do i turn a set of subqueries with similar/same criteria into another structure
What I got instead
a book about tuning and performance improvements
a book about embedded sql app-dev refactoring
I'm moderately disappointed, but I think this book will give me some knowledge that may help me invent 'real' t-sql refactoring patterns.