Quote Originally Posted by frantaylor View Post
You know that query execution time depends on the number of rows IN THE TABLE not the number of rows returned from the query, right? If you have 15 million rows in a table, it's going to take a LOT longer to select one row than a table with just a few entries?
No not right, that is not how database queries work. The time the database spends to find the row is not the only thing that costly. The overall speed depends on how many data is in the table, what data you want from the row, how you search for one row and on how you transport the data to the application.

A few examples:
- Imaging the following DB2 SQL query: SELECT myPrimaryKey FROM myTable FETCH FIRST 1 ROWS ONLY. This will be fast no matter how many entries are in the table.
- When you only query data that is indexed the database can highly reduce disk I/O (the slow part).
- If you have a network in between you and the database preselecting the data you need can highly reduce your network traffic.

Have you ever actually used a database? And not every program written presents you with a website viewable via the internet. There are many programs out there that just present data from a DB within a thin client to the user. It's not a good idea to always send all information you have to the client, because it slows down the client really fast.