> generally speaking you will not need indexes on tables that have few rows 
>  
> the definition of "few" varies with the particular table, the size of its  
> rows, and also on the "industrial strengthiness" of your database system  
 
This is true.  However ;-), I've done some query timing and found queries to be faster 
*with* an index on tables with as few as 20 rows (certainly any slow-down will be 
negligible).  When you start joining large tables to small ones, you might see a 
index speed up a query on a table with only 3 rows.  The factors are numerous but 
you get the picture.   
 
<tip type="SQL Indexes"> 
Here's my opinion:  At least create a primary key on all of your tables.  This will 
cover 80% of your queries involving that table.  Especially joins, which by design 
are mostly made up of foreign keys. 
</tip> 
 
<marginally interesting recent experience> 
I help support a legacy system (8-10 years old) and while looking for a bug on Monday 
noticed a table that could use another index.  We added the index and reduced the 
time required to print checks from 60 minutes to 5 minutes. 
</mire> 
 
 
> i could go on about this stuff for hours but we are really far afield from  
> the mainstream of web development topics, eh? 
 
I not so sure about being far afield of web dev. topics.  A high performance data-driven 
site can be killed by a poorly designed database.  Designing a fast database *starts* 
with the right indexes and writing SQL that uses those indexes.  If I could hammer 
one thing home today, it would be: "Learn how to tune your queries and database designs". 

 

Get Your Free, Private FarmDance at http://farmer.oracular.com/
_______________________________________________________________________

Free Unlimited Internet Access! Try it now! 
http://www.zdnet.com/downloads/altavista/index.html

_______________________________________________________________________