I have used db2, oracle, and sql server extensively, and I don't agree with any of the pro-db2 arguments above. Db2 is slightly more scaleable here but that is because it is sitting on a powerhouse mainframe machine. Oracle is extremely fast as well.
I would never, ever recommend using db2 to anyone over oracle as a blanket rule. There are certain instances where it makes sense, but there are tons and tons of them where it doesn't.
We aren't using the latest db2, but then again we aren't using the latest oracle. The db2 we use has major problems with the way it analyzes queries. Rather than use true optimizer hints, it "allows" you to do ridiculous things in your query that in fact should NOT be ways to signal the system to not use indexes. For example, SELECT FOO FROM BAR WHERE (A = 'FooBar' or 0 = 1). A good optimizer will ignore the 0 = 1 since it is always false and still use an index on A. Not DB2, that's their idea of an "optimizer hint".
It has completely crappy support for XML and ODBC/JDBC. In Oracle and SQL Server, you can have named placeholders in your SQLs, e.g. SELECT FOO FROM BAR WHERE A = :AFooValue. In DB2 you have to use ?. This makes architecting a data layer much more annoying and prone to problems. You must go to great lengths to not have your business layer tied to your particular DBMS, because with ? you must pass parameters in the exact order that they are present in the SQL, and if you have the same "parameter" twice, you must pass it twice. You can get around this with some architecture changes, but it's not pretty.
The development tools supplied with Db2 are awful. I'm not sure they are even better than nothing at all.
IBM also is notorious here (where we have been using db2 products for over 10 years) for releasing patches that cause a lot of problems. We had a version of db2 connect that actually was causing the db2 service to CRASH. Let's not even mention that the products written BY IBM for db2 often don't work. For example, the .net db2 drivers. There are several bugs in them that make it so we must also use ODBC connections at times because the native drivers are sending invalid CLI.
We have none of these problems with Oracle. The closest thing to a problem was an early version of the .net Oracle drivers witten by MICROSOFT which would leave connections open and orphaned. Which was fixed within a few months.
I prefer SQL Server as a developer, but I definitely understand why people are hesitant to use it.
I would never, ever recommend using db2 to anyone over oracle as a blanket rule. There are certain instances where it makes sense, but there are tons and tons of them where it doesn't.
We aren't using the latest db2, but then again we aren't using the latest oracle. The db2 we use has major problems with the way it analyzes queries. Rather than use true optimizer hints, it "allows" you to do ridiculous things in your query that in fact should NOT be ways to signal the system to not use indexes. For example, SELECT FOO FROM BAR WHERE (A = 'FooBar' or 0 = 1). A good optimizer will ignore the 0 = 1 since it is always false and still use an index on A. Not DB2, that's their idea of an "optimizer hint".
It has completely crappy support for XML and ODBC/JDBC. In Oracle and SQL Server, you can have named placeholders in your SQLs, e.g. SELECT FOO FROM BAR WHERE A = :AFooValue. In DB2 you have to use ?. This makes architecting a data layer much more annoying and prone to problems. You must go to great lengths to not have your business layer tied to your particular DBMS, because with ? you must pass parameters in the exact order that they are present in the SQL, and if you have the same "parameter" twice, you must pass it twice. You can get around this with some architecture changes, but it's not pretty.
The development tools supplied with Db2 are awful. I'm not sure they are even better than nothing at all.
IBM also is notorious here (where we have been using db2 products for over 10 years) for releasing patches that cause a lot of problems. We had a version of db2 connect that actually was causing the db2 service to CRASH. Let's not even mention that the products written BY IBM for db2 often don't work. For example, the .net db2 drivers. There are several bugs in them that make it so we must also use ODBC connections at times because the native drivers are sending invalid CLI.
We have none of these problems with Oracle. The closest thing to a problem was an early version of the .net Oracle drivers witten by MICROSOFT which would leave connections open and orphaned. Which was fixed within a few months.
I prefer SQL Server as a developer, but I definitely understand why people are hesitant to use it.
