>Well, you could run gobs of speed tests on different machines to cover allt he different situations...
>
>But of course, there are ways to mathematically describe precisely what you are doing. From these equations you can then gain a better understanding of how things work, and develope heuristics. Unfortunately I left my database design books at school, which is a few hundred miles away. I forget who wrote the first article, prolly someone like Jim Gray. Anyway, you might not have encountered them too much in design, because they come in handy moreso if you are designing a db (e.g. oracle, vfp, mysql, etc.) but they are real handy to know anyway, because like I said they give you a better understanding of the implications of the choices you make.
>
>matt

The point is that because we know only partly what is really going on, we can make wrong assumptions. A sound theory is of help, but it is convenient to test the assumptions.

For instance, I learned, and believed for years, that joining two tables on integer keys would be faster than character keys, because integers are usually smaller. Real-world revealed that the joins on integers were actually about 10% faster (the comparison involved two tables, and 10-byte character keys). My current assumption is that this is due to built-in data compression for indices.

Anyway, you can make a lot of assumptions about how the data is retrieved, and what you should do to optimize it - but it is always worthwhile to test different options.

Hilmar.