>>I am always telling people to *measure* performance if there is an issue, but the trick is to measure something relevant to your app. For a web app that means measure the edxpected no. of connections hitting at the same time and measuring n-fold hits as well to approximate scalability. For a desktop app you might compare reading all data with one connection or opening additional connections and reading in background/parallell if massive amounts of data are read. But - how often do you plan to use select * whithout where-clause in your app ?
>
>If you are comparing the basic performace of different databases, then isn't this the first thing to check? another would be speed of making a connection. Anyway mine is a C/s app and such a test is relevant because I am changing the database.
>And I agree with you on this that there are a million things further than that including app. architecture, design, platform, etc. which are best considered before selecting your tools.
>The sad thing is that there is no clear cut guidlines or benchmarks available for databases to make your decision easy.:(

Hi Aman,

I think the point that Thomas was trying to make was that SELECT * doesn't really have a place in a proper client server application. Most times you will be limiting the data you pull over the wire based on some criteria, so it probably makes more sense to test a query with a WHERE clause that will be similar or the same as what your software will be doing. But then again, if your software does bring down all the records over the network, then SELECT * will be the best test for you.