From reading that article, I am under the impression it moreso tested "what database has the best drivers for our platform" as opposed to "who has the best database engine." I think the only way they could really test engine strength is if they built solutions in a variety of development platforms, JAVA, ASP, PHP, etc and then compare results for each of these. But of course this would take a lot of work and so it probably won't happen.
Originally posted by crowdozer From reading that article, I am under the impression it moreso tested "what database has the best drivers for our platform" as opposed to "who has the best database engine."
That's the impression that I received as well.
Plus, it looked strictly at performance -- not 'ease of use', development time, etc.; e.g. Total Cost of Ownership. Oracle 8i has like a 1GB footprint (e.g. takes up a GB on your hard disk), and I think 9i is around 1.5GB. MySQL is tiny, Sybase ASE is around 200MB, etc.. Oracle is a BEAR to administrate/configure, MySQL / MS SQL are really easy to configure. MySQL has poor replication, and may suffer more downtime per year than Sybase ASE which has the best replication of them all, but costs a lot of money. etc.
As I always say: Use the best tool for the job!. People who take benchmarks seriously are either Zealots who say "We're #1! YEAH! Everyone should use our product now!" or managers who think that this is the only yardstick you need to decide on a RDBMS platform.
I'd say this is a clear LOSS for Oracle, seeing as it is roughtly 10 to 15x more expensive than Sybase but only 1.5x faster. And it is infinitely more expensive than MySQL which is free!
Plus they only stopped at 1000 users. 1000 users really isn't that much nowadays. I'd rather see 5,000 and 10,000 users -- see where the RDBMS's start choking and dying off. I want to know what is the MAX not when it plateaus.
Also with MySQL they state the Record Cache is what they used to get those stellar numbers. Without it was roughly 2/3rds less (sux0r!). To really test MySQL you need to mix a lot of inserts/updates as well, you know, the things that really kill it but are pretty much often-used in most OLTP systems (yeah if you're a magazine site you can live with static content but you'd be better off pushing it to HTML in the first place!). I want to know what the overhead is in maintaining the record cache (updates, inserts, deletes will invailidate the record cache and it will need to be regenerated). What if 10% writes totally kill the system due to the record cache overhead? It could negate the performance benefits.
To MS SQL Server's credit, they concede that the JDBC drivers weren't the best. Then why did they use them in the first place! If I understand it correctly, JDBC is like ODBC in that it offers 'one-size-fits-all' connectivity, right? It's well known that ODBC is far slower than the native DB libs -- so you'd never use it in a production environment without some sort of logic dictating that you HAD to. Same thing here. Why not use the OCI layer for Oracle, or the Sybase-CT libs for Sybase. Or the .NET libs for MS SQL. That is what you would use if you really wanted to squeeze performance out of your system.