> So..what would be faster for a db backed auction?  Lots of  Tables with all
> similar items in them or one table with all items in it.

Put them all in one table.  There is no trade-off.  You will not get any performance gain by splitting them into multiple tables, only headaches and messy code.

Generally, if you index your table properly and write good code, it won't take any longer to search through 100,000,000 records than it will to search through 1,000.  

Why is this?  That's where the index thread comes in I guess.  The simplified explanation of an index offered by Rob is a binary search.  It is how you would search through a book to find a certain page.  It's a good mental picture but a DBMS will not actually use this method.  DBMSs will normally use B-tree, Hash, or Bitmap indexes (Mostly B-tree).  See your computer science texts for more information about index types.  At this point in the discussion, we will settle for knowing that:

- B-tree performance is good for both small and large tables, and does not degrade as the size of a table grows."

- All leaf blocks of the B-tree are at the same depth, so retrieval of any record from anywhere in the index takes approximately the same amount of time. 

- B-trees provide excellent retrieval performance for a wide range of queries, including exact match and range searches. 

- Inserts, updates, and deletes are efficient, maintaining key order for fast retrieval. 

Copyright © 1999 Oracle Corporation. 
All Rights Reserved. 

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

_______________________________________________________________________