At my work we have a small database (as in two hundred tables and maybe a total of a million of rows or so).
I\'ve always expected it to be quite fast in the order of se
Indexing is a major factor here, when done properly they can speed up Select statements quite well, but remember that an index will bog down an insert as well as the server not only updates the data, but the indexes as well. The trick here is:
1) Determine the queries that are truly speed critical, these queries should have optimal indexes for them.
2) Fill factor is important here as well. This provides empty space to an index page for filling later. When an index page is full (enough rows are inserted), a new page needs to be created taking yet more time. However empty pages occupy disk space.
My trick is this, for each application I set priorities as follows:
1) Speed of read (SELECT, Some UPDATE, Some DELETE) - the higher this priority, the more indexes I create
2) Speed of write (INSERT, Some Update, Some DELETE) - the higher this priority, the fewer indexes I create
3) Disk space efficiency - the higher this priority, the higher my fill factor
Note this knowledge generally applies to SQL Server, your mileage may vary on a different DBMS.
SQL Statement evaluation can help here too, but this takes a real pro, careful WHERE and JOIN analysis can help determine bottlenecks and where your queries are suffering. Turn on SHOWPLAN and query plans, evaluate what you see and plan accordingly.
Also look at SQL Server 2008, indexed Joins!