Beginning SQL

Chapter 13
Again, the shotgun approach just as often causes problems as solves them. Adding indexes may very
well speed up whatever it is you are trying to speed up, but it may cripple some other piece of the application.
Deleting an index may speed up one part of the application but cripple another.
The intention here is not to cripple you with fear of doing anything because you may cause more problems
than you fix, but simply to cause you to always think about the implications of your changes,
beyond the area you are working on. Whenever you make a change, particularly on a large system, you
need to keep your ears open to users complaining that the application seems slower lately. Where possible,
record the changes that you make so that they can be backed out if necessary.
Why Do You Do It?
356
The answer to this question is always “because someone complains that a process is too slow.” It is nevertheless
useful to ask the question because thinking about the answer puts the problem squarely into
perspective. There is never just one task to do in a system; as a developer, you are always juggling your
time trying to get the most important things accomplished first, then moving down the list to less important
things.
I once had the honor of redesigning a call center application. Since there is never enough time, I took
some things that worked and just used them with as little modification as I could get away with and
concentrated on getting other more important tasks accomplished. The application had a search screen
that looked up a person on a variety of conditions — claim number, social security number, last name,
and first name. Any of these were supposed to be searchable on just pieces — the first few characters of
the last name plus the first few pieces of the first name, any number of characters of the SSN, and so on.
Once the data search was entered, a set of matching records was pulled. The user would then select one
of those records and pull the information about that person.
The original application had only a few thousand claim records to search through and the database was
horribly normalized, so the application designer just pulled all of the records out into a record set that
the form could display, left the form open, and then moved back and forth in that record set, keeping the
form open and the data set loaded. Once a primary key of the record was found using the search algorithm,
it was lightning fast to get to that record.
Having correctly normalized the database, the process of pulling all that data was a tad more complex
and took a lot longer, and it also took a lot longer to move the form to the right record. It became much
faster to just ask the database for and display a single record at a time. In the end, I used almost exactly
the same query for the data entry form, but I placed a WHERE on the primary key that retrieved only a
single record instead of all the records and then asked the form to move to the right record for each
search.
The point is that, yes, I did optimize the query, but not in the way you might expect. I didn’t add any
indexes; I didn’t modify any joins. I actually examined the process and discovered that a different way of
performing the process was in order.