Open Source Database Underdogs
implex writes "Interactive Week had an article called "Data Underdogs" which they compare offerings of present Open Source Databases with present commercial offerings. In one part they mention ...On the other hand, MySQL developers now have a much-needed transaction management system: NuSphere last month made its Gemini transaction manager for MySQL available as open source code on mySQL.org, a site that the company recently launched. Complicating matters, though, is NuSphere's blood feud with MySQL AB, a Swedish company that runs a competing open source development site for MySQL code at www.mysql.com. No mention of the fact that MySQL AB actually created the product was interesting."
Instead of focusing in on the available solutions, the article simply spits out the idea that MySQL and Postgres are weak pretenders.
The FACT is that these databases are excellent solutions to a large number for MOST database problems. Sure, like all DBMSs, they can always use more features. But I don't want my DBMS to turn into an uncontrolled monster like Oracle.
For 99% of the applications out there, Postgres and mySQL fits the bill. If you're doing large scale distributed payroll using SAP, then I suggest you go with a big name...
But if you're an average-sized business, Postgres is a full-featured solution today. It is an inexpensive, fully-capable solution.
If you're into writing Oracle PL/SQL, a proprietary procedural extention to SQL, go with Oracle. (Note: PL/SQL doesn't work with Sybase or DB2 or anything else.) If you're into TransactSQL, another proprietary SQL extension, go with Sybase. Once you get into TransactSQL, you'll NEVER migrate out without expense. In fact, my shop, an Oracle shop, doesn't PERMIT developers to use the PL/SQL ewxtensions. We learned our lesson after migrating from proprietary MS-SQL-Server extensions to Oracle!
And if you need a big company to support your 20,000 person payroll, go with IBM's DB2. Again, another fine DBMS.
But for the average shop? Save your money and go with PostgreSQL.
Companies keep everything on database systems. Hundreds of geek-hours must go into the design of a database application for a company. Whatever system a company chooses, they must be reasonably sure the system will:
- almost never fail
- be supported by a stable company and
- integrate well with other systems, into the future.
A smaller price tag may be a good start to target smaller companies that don't rely heavily on database applications, but the reason Oracle can charge $15k/CPU for 9i Standard: the reputation is worth it."Databases are dramatically more complicated than any Web server or operating system technology."
The above is a quote from senior marketing director Bob Shimp, from the article. I will give him the Web Server - which is not to say that it is not complex, but likely not as complex as a robust relational database. I cannot do the same for the OpSys. There is a dramatic difference in the levels of complexity between a monolithic single-user non-multitasking operating system (such as DOS) and a multiprocessing distributed parallel asymmetric (etc etc) OpSys. The quote is not grounded in any sort of evidence, and I have serious doubts as to whether the 'marketing director' would have ever encountered a kernel that did not come from a bag marked 'Orville Redenbocker'. It is simply misguided and misinformed, and the general intent seems to be in undermining confidence in Open Source DBs. (... furthering the myth that open source is 'unreliable'.) Threatened? He likely should be.
I'd like to see an object data model (ODM) open source database come into the scene. Now that would cause a ruckus, challenging both the bottom line and validity of the relational model!
SQL is not SQL
There are four tiers to the SQL-92 standard, and even commercial RDBMS vendors to not conform to all of them.
Oracle, Informix, DB2, MySQL all have different optimizers and differing concurrency schemes. Oracle does not lock a row for reading when another transaction is writing a row. Informix will perform table scans on certain queries where DB2 will not.
This "growing trend" you are talking about must be coming from inexperienced programmers working on trivial or single-user applications. In REAL-LIFE the security of data and usability of the client are paramount.
The fact that you would even say that MySQL and Oracle do the same thing displays your complete lack of knowledge regarding what modern commercial database products are capable of. Leaving all the programming logic in the hands of applications developers re-invents the wheel, escalating costs while introducing more bugs into the system.
Conformity is the jailer of freedom and enemy of growth. -JFK