Feature

Eight Sound Reasons Not to Use MySQL

Why and when should you give the thumbs down to MySQL?

By Brent Toderash

PAGE 2

Integration With an Existing Environment
I know of one large IT shop that has site licenses for Oracle and Sybase, and a number of specific licenses for MS-SQL Server. In this shop, the MS-SQL instances are largely the result of the ignorant department staff who don't know they paid for site licenses for other databases. The addition of MySQL (or any other database) is an unwise idea in this context, given that the DBAs already have enough environments to deal with. In situations with pre-existing database environments, it is pretty much axiomatic that the management burden is diminished if a common platform can be maintained. Further, if the company already owns licenses to a proprietary system, one of MySQL's major strong points is negated.

Product Maturity
By way of comparison, Oracle will hit the 30th anniversary of its first product shipment in 2009, at which point MySQL will not yet have hit half that distance from its first release. For its part, Microsoft SQL Server is only a couple of years older than MySQL, but its first release was based on Sybase, which was at that time six years past its first release. As for the other notable open-source database, PostgreSQL will in 2009 hit the 20-year mark from its first release. While MySQL is not the newest database on the market, there are older, more established alternatives—and for many, that's reason enough. To be fair, this is in my view not a particularly strong reason to opt against MySQL, but at the same time, I'd be hard-pressed to tell a conservative IT manager making a platform decision for a mission-critical application based on this factor that he's doing the wrong thing.

Feature Set Maturity
While some are tempted to compile an overview feature comparison of MySQL versus other systems to use as an authoritative decision-making tool, in many respects this is a mug's game. As new software releases or patches are issued by any of the vendors, the list becomes rapidly outdated. Further, features that are important to some applications have no relevance to others, such that "10 percent more features" is really a measure of no consequence. What does matter is whether the feature set at the time of release matches the requirements, or matches closely enough.

Sometimes, you can compensate for missing features with workarounds, such as a join instead of a subquery in MySQL prior to version 4.1. Most of the required features for an RDBMS are firmly in place with the release of MySQL 5.0, but we can legitimately consider the maturity of some of these features as a possible reason to shy away from MySQL. For example, the lack of views, triggers and stored procedures has historically been the major criticism of MySQL. These have all been supported by MySQL for a year or so now, but by comparison, they have been features for about 10 years in most competing RDBMSes.