look into Big O Notation:
http://en.wikipedia.org/wiki/Big_O_notation

Analyzing the performance of algorithms processing varying amounts of data is a science. Often times, more hardware isn’t going to matter.

I recall a story of a database app a company had written. It was slow in production, so they added 10x the hardware at the server side, but it was still slow, so they hired a top level consultant to come in and help them figure out how to speed it up.

First question the consultant asked was, “Have you indexed the tables?”

“Index?” the client asked…

If you have a program that requires 600 MB of RAM and you want to run it on a machine that only has 500 MB installed, it’s surely cheaper and easier to just upgrade the memory. (I’m skimming over issues of virtual memory and all to make the point.) But I have had many occasions where I have found that, for example, a program requires exponentially more time to process more records. So our little test database of 100 records runs in 5 seconds, but when we increase it to 200 records it requires 15 seconds, 300 records requires 45 seconds, 400 requires 135 seconds, and it quickly becomes obvious that when we get to a real database with a million records there won’t be enough computer power in the world to do the job in our lifetimes. At that point you need to revisit the algorithms and come up with a fundamentally different approach.

By the way, while I realize that there are times when throwing more hardware at it is the right solution from a cost-benefit perspective, I find this very emotionally unsatisfying. I take pride in my work and I want to write the best program I can. When I have to stop and say, “Hey, it’s good enough; put it into production and get on to the next task,” that just offends my sense of pride. I suppose craftsmen go through this all the time: Yes, you’d really like to spend another few weeks making that piece of woodwork absolutely perfect, but if you do it will only increase the potential selling price by a couple of dollars, no way is it worth your time.

Hey, can I get in a shameless plug for my book? “A Sane Approach to Database Design”. Available at “electrictactics.com”. Probably on Amazon by the time anyone reads this post.

As well as full table scans, there’s a locking - sometimes deadlocking - issue (which full table scans are more likely to reveal, of course). See OraStory for one anecdote. The FK locking behaviour has changed over time (sorry, can’t find a good reference or version number quickly).

right tools for the job.

The article and query at ixora’s site is here - the year was 2000. We miss you Steve. :-)

Paul