Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Databases Programming Software IT

8 Reasons Not To Use MySQL (And 5 To Adopt It) 288

Esther Schindler writes "Database decisions are never easy, even — or maybe especially — when one choice is extremely popular. To highlight the advantages and disadvantages of the open-source MySQL DBMS, CIO.com asked two open-source experts to enumerate the reasons to choose MySQL and to pick something else. Tina Gasperson takes the 5 reasons to use MySQL side, and Brent Toderash discusses 8 reasons not to. Note that this isn't an 'open source vs proprietary databases' comparison; it's about MySQL's suitability in enterprise situations."
This discussion has been archived. No new comments can be posted.

8 Reasons Not To Use MySQL (And 5 To Adopt It)

Comments Filter:
  • by mugnyte ( 203225 ) on Friday May 25, 2007 @04:56PM (#19275727) Journal
    ...Fanboi RDBMS wanker post race begins.....


      Seriously, the articles do nothing more than point out the *best places* MySQL may or may not work, not that it is better than anything.
      One size yet again does not fit all.

        Hmmm..where's my Model204 [cca-int.com] manuals...?
    • Re:Ready...Set... (Score:5, Insightful)

      by jrockway ( 229604 ) <jon-nospam@jrock.us> on Friday May 25, 2007 @05:53PM (#19276435) Homepage Journal
      These two articles were some of the worst pieces of literature I've ever seen in my life. The GPL and BSD licenses are "too free"? "Ajax" is a programming language powered by MySQL? Etc., etc. Oh my God... what crap!
  • by mgkimsal2 ( 200677 ) on Friday May 25, 2007 @04:58PM (#19275747) Homepage
    1. MySQL Uses the GPL
    2. MySQL Doesn't Use the GPL
    3. Integration With an Existing Environment
    4. Product Maturity
    5. Feature Set Maturity
    6. Availability of Certification
    7. Corporate Considerations
    8. Perception of Scalability

    They all have *some* merit, but all are very dependent on your situation. 1 and 2 seem to cancel each other out, as in if #1 is an issue for you, #2 probably wouldn't be. #3 is sort of weak, arguing that if you already have many other databases, adding yet another different system is detrimental. That's not an argument against MySQL, but against disparate systems altogether. The rest of the issues are matters of degree. "While MySQL does have a certification training program, its training availability is not nearly as widespread as for, say, Oracle or MS-SQL Server." True, but if you're comfortable with the level of quality of certified MySQL people, then go forward. It'll contribute to the general upward spiral of adoption, hiring, certification and so on. MySQL is going to keep growing, it's just a matter of how quickly and in what directions.

    P.S. Printable version here -> http://www.cio.com/article/print/113111 [cio.com]
    • by EsbenMoseHansen ( 731150 ) on Friday May 25, 2007 @05:10PM (#19275905) Homepage

      Are those supposed to e reasons? How about

      • Command line completion in mysql client sucks
      • Transactional support is a bit sub-par compared to postgres.
      • Unless carefully configured, not nulls, group bys and quoting are broken.
      • Sequence support is also a bit sub-par.
      • Some entity name's case sensitivity is dependent on host filesystem
      • Subselect support slow and memory hungry (I've only tested this a little)
      • Blobs cannot be accessed as streams

      Only 7, but all of those are real real complaints :)

      • The article is in CIO magazine, none of the downsides you mention is of a concern for a CIO. A Product manager? Maybe, even then probably not.
        • by EsbenMoseHansen ( 731150 ) on Friday May 25, 2007 @06:00PM (#19276491) Homepage

          The article is in CIO magazine, none of the downsides you mention is of a concern for a CIO. A Product manager? Maybe, even then probably not.

          If you are in any position where you are choosing between databases, you have three cases:

          1. You understand these issues
          2. You have delegated the decision to someone who does
          3. You are incompetent
          4. You are toying around

          Sorry about the M.P. reference there :o)

          • Of course if you want to make your product (that runs on a db backend) available to MySQL users then your decision has been made for you already.
          • Re: (Score:3, Insightful)

            by SavvyPlayer ( 774432 )
            You left out a case:

            5. You have delegated the decision to a well-funded, trusted team of veteran IT decision makers.

            Businesses live and die by information, so the severity of your list of relatively insignificant defects rather depends on the criticality of the data in question. When lives are at stake (economically, physically or medically), when every hour of system downtime costs your operation tens or hundreds of thousands of dollars, decisions are based on higher level concerns. The integrity of the da
      • by larry bagina ( 561269 ) on Friday May 25, 2007 @05:44PM (#19276325) Journal
        #8: "February 31, 2007"
        • Re: (Score:3, Informative)

          #8: "February 31, 2007"

          I almost included that one, but they have actually fixed that 5.02. You can still specify ALLOW_INVALID_DATES as an sqlmode for that nostalgic feeling, though.

        • Re: (Score:3, Interesting)

          by jadavis ( 473492 )
          Another one:

          Does MySQL still use a rule-based planner?

          Without having an effective cost-based planner (like PostgreSQL) the performance for non-trivial (from a planning perspective) queries will never be competitive.

          If using a rule-based planner, how does MySQL know when to use a hash aggregate versus a sort + group aggregate? How does it determine join order without keeping statistics about the nature of the data stored in the tables? How does it know whether to hash join vs. merge join? What happens when t
          • Re: (Score:3, Informative)

            by LLuthor ( 909583 )
            Last I used it, mysql never needed to use a cost-based optimizer simply because it never could do anything but nested-loop joins. Sadly this means that ANY non-trivial query can bring mysql to its knees for ALL users connected to that server instance.

            Compared to PostgreSQL's optimizer, which tried very very hard to avoid nested loop joins, and can handle medium sized queries (upto around 16-table joins) with relative ease, its a real burden to port apps to work with mysql.
      • I could be mistaken, but I thought Connector/J 5.0 supported retrieving BLOBs as streams if you used the MySQL specific API and not just generic JDBC.

        The latest production version of the driver is now 50-100 percent faster in most situations than the previous version. It also creates fewer transient objects than before, leading to better performance and even more stability. The driver now also supports "streaming" result sets, which allows users to retrieve large numbers of rows without using a large memo

        • by Shados ( 741919 )
          From the description you pasted (and I didnt check on my own), the wording is a bit misleading: its talking about streaming the result set itself for when it has a lot of -rows-, not streaming a single field when that field is too large. And the rest simply talks about what size of blobs it can push at all.

          What the other poster meant, is let say I have a 1 gigabytes AVI file in a row, its possible (at least with other DBMS) to open that particular -field- as if it was a file on the file system, and to strea
      • by TopSpin ( 753 ) * on Friday May 25, 2007 @06:37PM (#19276961) Journal
        Does MySQL still truncate data that doesn't fit? I recall similar lists of criticisms posted here and elsewhere about MySQL and one of the entries is that numbers 'too large' or strings 'too long' for a given column are just silently whacked down to size. I thought then and persist in thinking that this behavior is pretty damning.

        • by Snover ( 469130 ) on Friday May 25, 2007 @08:35PM (#19278305) Homepage
          You can set SQL modes, such as STRICT_ALL_TABLES, that will cause MySQL to reject invalid data instead of truncating it. There is documentation [mysql.com] about the various SQL modes.
          • by rbanffy ( 584143 )
            This should never, ever be even considered to ship enabled.

            It is so horrid it should be forbidden and deemed illegal in any sane jurisdiction.
          • by Ed Avis ( 5917 ) <ed@membled.com> on Friday May 25, 2007 @09:31PM (#19278757) Homepage
            That is great to hear. The only question I have is why on _earth_ the safe (and standards-compliant) mode isn't the default, with the weird MySQL-only accept-Feb-30-as-a-valid-date kind of behaviour enabled with a special option for those who really want it.

            It's this kind of thing that makes me still suspicious of MySQL. I hope that for the next release - 6.0 or whatever it is - they can make a clean break with historical stupidity, and release a DBMS that gives safe, ANSI-compliant behaviour out of the box. However, there's nothing wrong with letting the sysadmin deliberately loosen some of the transactional constraints in cases where ultra high speed is important, although note that for all its supposed emphasis on speed over correctness, MySQL is slower than Postgres [blogspot.com].
            • by spyowl ( 838397 ) on Saturday May 26, 2007 @12:21AM (#19279811)

              It's this kind of thing that makes me still suspicious of MySQL. I hope that for the next

              release - 6.0 or whatever it is - they can make a clean break with historical stupidity, and release a DBMS that gives safe, ANSI-compliant behaviour out of the box.

              Your suspicions are correct generally. However, your hopes may have to live a little longer because if the next version of MySQL is based on anything that they have out today you may be in for a disappointment. Here are my real reasons not to use MySQL:

              • MySQL is not scalable: there is no table partitioning. As your data grows and so does your use of the database, you'll find your options for scalability are very limited to what you can "hack" around on your own. Other RDBMS solutions like Oracle, MSSQL, and yes, even Postgres have anywhere from decent to excellent scalability.
              • Advertized "enterprise" features are hacked into the stagnant and very monolithic MySQL codebase and frequently do not deliver as advertized. Here are examples: Sub-selects are not well optimized, if at all; indexes cannot be used more than once in the same query to help with optimization; using a combination of triggers and stored procedures within transactions in a medium to high usage environment results in crashes that even MySQL cannot explain; row-level locking only exists if you only have primary key, and no other indexed columns that you need to update, and you are updating using that primary key; does not truly support MVCC [wikipedia.org] - even with InnoDB your selects may block updates and the other way around; replication forces further limitations in concurrency; the list can go on and on. None of these are a problem to any noticeable extent with any of the other "enterprise" RDBMSes.
              • More on replication: even though MySQL has somewhat elegant solution for replication, besides limiting concurrency (as already mentioned) and introducing serialization, this solution poses additional tricky fundamental problems. For example, it is nearly impossible to implement a true multi-master replicated environment.
              • No HA solution: Oracle and MSSQL (recently and more limited) offer true HA solutions that can increase your database availability in case of failure, and within the HA environment guarantee the transactions and data the applications were led to believe was successfully manipulated. This cannot be achieved with heartbeat and replication using MySQL, or even Postgres for that matter.
              • Critical bugs dealing with data consistency: This is not a statistical analysis, but MySQL has had and still has a lot of critical bugs dealing with critical part of the RDBMS - data. e.g., you cannot rely on RDBMS for storing your data if, when queried under certain circumstances, it returns NULLs when it should return the correct data. It is not fully comprehensible how a product released as stable (such as version 5.0) can still have so many critical data-related bugs.
              • Horrible codebase: If you are at least a decent programmer, please have a look at MySQL code: monolithic, one main file with succession of countless if blocks for parsing, optimizing and running queries; features such as triggers, stored procedures, and replication visibly hacked in to the existing "bad" design. There's very little abstraction that can leave data files in inconsistent and unreadable state in the event of the server crash (mostly MyISAM). And then, just for kicks, please have a look at Postgres source code: well-organized, separated into well-designed components you'll get acquainted with certain satisfaction to components that do parsing, planning, optimization, execution, and other functions. Code is well-commented and, as a programmer, it will give you a certain comfort when dealing with the software. This is a very important point and demonstrates why Postgres, for example, having a solid foundation, can implement advanced features (such as transaction savepoints,
          • I suppose the default mode is CORRUPT_DATA_SILENTLY?
      • Seeing as you seem to know a thing or two about MySQL...

        So how does its procedural code, trigger capability, and user defined functions compare to Oracle?
        Is it possible to port between them without jumping through too many hoops?
        Does MySQL support partitioning?
        How about performance with large dbs?
    • by Shados ( 741919 )
      Btw, #3 is actually a -crazy- big deal. DBMS like Oracle and SQL Server, for all their flaws, have incredibly powerful tools to integrate with legacy environment. There are NOT many ETL specialists around, and those that are free tend to charge premium for their services, making less well known products (3rd party) to be prohibitively expensive to use in the long run, so you're better off using the built in stuff. The commercial DBMS tend to be a blessing in that department.
      • I will agree with this, we are currently looking to migrate a legacy UNIX system (in a language you have never heard of, Sculptor, with data stored in what essentially amounts to a proprietary CISAM file with no database engine but can only be accessed by said language) to an MS SQL driven system (yes, we looked at everything, and MS SQL and .Net came out top, and thats coming from me, the company UNIX guru).

        I can tell you right now, SSIS is fantastic for what we want to do, especially integrating with t
        • by Shados ( 741919 )
          Yup, I'm our company's SSIS guru (I don't know how I ended up there, I'm an asp.net developer, but oh well...), and it is great, we even use it to do some system orchestration between a bunch of legacy system, our business partners, DB2, and a bunch of other things (even using some custom SSIS tasks and components that I made). Its awesome.

          In this day and age, the data engine itself is just one part of the equation.
    • It should be noted that mySQL is planning an IPO, scratch one of their points. http://slashdot.org/article.pl?sid=07/04/26/021121 0&from=rss [slashdot.org]
    • It is painfully obvious from the article that this writer was or is a consultant. All of the reasons not to use MySQL are PHB reasons. Not one is based on actual abilities or inabilities of MySQL. He seems to be intent on agreeing with a position that he doesn't understand or didn't want to take. "...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." Yes, it does sound like he would be har

  • by ezh ( 707373 ) on Friday May 25, 2007 @04:59PM (#19275761)

    #1. MySQL uses GPL
    #2. MySQL does not use GPL


    System.out.println("Nothing here to see. Please, move along...");

  • by DaleGlass ( 1068434 ) on Friday May 25, 2007 @05:00PM (#19275783) Homepage

    In these situations, if the BSD license of PostgreSQL is still too "open," a commercial license is preferred.
    This is plain bizarre. How can a closed license be preferrable to BSD, when BSD is basically "do whatever you want with it", including closing the source?
    • by Rycross ( 836649 ) on Friday May 25, 2007 @05:04PM (#19275817)
      Obviously giving the author credit for originally writing the code is just too demanding.
    • by RingDev ( 879105 ) on Friday May 25, 2007 @05:06PM (#19275841) Homepage Journal
      And another gem FTA... "Whatever one might say about the strength of MySQL's backers, the fact that the company is not publicly traded means the financials are not required by law to be a matter of public record."

      So we're going to have to trust the software company that won't show us their code, but will show us their books instead of the company that will show us the code, but not the books?!?

      The 8 reasons are completely bunk, I thought I might actually learn something reading that article as we are about to increase our MySQL presence here, but that was a complete was of time.

      • by DragonWriter ( 970822 ) on Friday May 25, 2007 @05:39PM (#19276259)

        And another gem FTA... "Whatever one might say about the strength of MySQL's backers, the fact that the company is not publicly traded means the financials are not required by law to be a matter of public record."

        So we're going to have to trust the software company that won't show us their code, but will show us their books instead of the company that will show us the code, but not the books?!?

        In business, this often makes some sense. The purchaser doesn't want to see and maintain the code, that's not their core competency. They want to be assured that, however, the vendor they get support from will be around to provide support in the future. So they are more concerned with the financials than the code.

        Its just outsourcing in its original sense (before what used to be either "overseas outsourcing" or "offshoring" became the dominant definition): focus your company on its primary mission, and contract out for everything else.

      • I didn't read the article, but indeed, what load of BS. Do we need to know their books? Companies might mess with their books to look better for their (porspective) stockholders. In the case of MySQL, I don't know if they sell stocks outside of the public trade, but if so, then I'd say that their openness of their books is a matter of importance only for those who can and want to invest in them.

        Here in Germany there are several supermarkets completely out of public trade. And they are doing very well inde

    • by NevDull ( 170554 )
      Perhaps to avoid liability?

      Some of his statements seemed to be about inclusion of the database in another product...

      With the SCO v. Novell lawsuit on the front page, it makes me wonder if this is the underdeveloped idea he was getting at.

      • Even if this is about tight integration of the RDBMS into a redistributable product, the statement about PostgreSQL doesn't make sense. Do what you want with it is always do what you want with it. The author is throwing arguments from different viewpoints out as if they ought to be arguments from one viewpoint. Sure, there are those in the open source community that say BSD is too free that all should be GPL, but that's hardly going to be an argument from a user perspective, no matter what the user wants
    • How can a closed license be preferable to BSD, when BSD is basically "do whatever you want with it", including closing the source?

      Because they don't understand licensing. I've run into the same kind of thing with public domain software. Couldn't plug it in because they didn't understand that you didn't have to pay (or worry about legal issues with) public domain software, but were concerned support might not be there. Well - we had the source, but couldn't integrate it. So it the feature it would have sup

    • by tacocat ( 527354 )

      My company has a policy rejecting the application or use of any GPL or F/OSS software.

      I'm not kidding...

  • Not all database types are fit for all purposes. Relational databases for instance are bad for data mining/warehousing due to poor query performance but good for data entry due to high transactional performance
    • Re: (Score:3, Informative)

      by Shados ( 741919 )
      The more advanced RDBMS engines have OLAP/Datawarehousing support built in. For example, in SQL Server, thats SSAS, and it works wonderfully well, and is as integrated as it can be. Oh, one can argue that its technically a "separate" database, but from an installation, licensing and development point of view, they're one and the same. (Analysis Services also happens to be the market leader in that department...).

      Thats just an example, and while thats Microsoft, I'm sure there are plenty of non-Microsoft equ
      • by guruevi ( 827432 )
        He wasn't talking about whether or not it's integrated. He's talking about the performance. I can bolt on a datawarehousing application on anything and it will work, the performance is what counts. And I know from experience that MS SQL2005 (what you are talking about since 2000 doesn't have it) is sub-par on performance for that kind of work on very large datasets mainly because of the performance limitations of the underlying system (Windows). Well, the solution is there now (we bought something from one
        • by Shados ( 741919 )
          SQL Server 2000 does have OLAP/Datawarehousing. It came in, in the second edition of SQL Server 7, I beleive.

          And I know he wasn't talking about weather or not its integrated. The thing is, he was saying how a relational database won't be on par for performance in datawarehousing/BI environments. That is correct, except when you install SQL Server, you get more than one "engine". The main one that everyone thinks about is a relational database. Analysis Services is NOT a relational database. It is an OLAP cu
    • by dedazo ( 737510 )

      Relational databases for instance are bad for data mining/warehousing due to poor query performance

      Products like Hyperion Essbase have made this argument pretty much obsolete.

    • hmmm, very incorrect (Score:5, Informative)

      by kpharmer ( 452893 ) on Friday May 25, 2007 @07:34PM (#19277657)
      > Not all database types are fit for all purposes. Relational databases for instance are bad for data mining/warehousing
      > due to poor query performance but good for data entry due to high transactional performance

      Your information is incorrect:
      1. relational databases have been used for warehousing and reporting (data marts) for 15 years - and are used for more than any other solution for this purpose. Ok, sure you've got a lot of OLAP out there, but there's probably almost as much Relational OLAP (ROLAP) via Microstrategy, etc as there is true OLAP.

      2. Take db2 for example, it:
              - support three different forms of range partitioning (union-all views, multi-dimensional clustering, and range partitioning)
              - supports hash-partitioning of the data across many servers - think "beowulf cluster"
              - given the two above you can spread your data across 100 4-way servers, each with fibre access to a heavily-cashed SAN.
              - Now when you issue a query db2 will spin up all 100 servers - each hitting its own local piece of the data (not 100 copies of the whole data, but each server with 1% of the whole).
              - Because it also supports range partitioning each server is probably only going to scan 10% of the total data in a typical query.
              - Because it support query parallelism it'll split each query on each node into four separate pieces (getting near-linear performance speedups) - now you've got 400 cpus working.
              - Because its optimizer is about the best one on the market - it isn't going to auger itself into the ground on your 100 line sql query.
              - That should allow you to crunch down a billion rows to your 24 row output in couple of seconds at most.
              - Of course, it's also smart enough to rewrite your query to automatically hit any summary table that could speed the query up. So, it may only have to scan 2400 rows - and may return the results in 0.001 seconds.

      3. The point is that warehousing, reporting and analytics work very well in a relational environment. But you need to pick your products well. If you want to handle terabytes of data you can put it in MySQL, SQLite, MS Access, Foxpro, etc - if you really had to. But, life will be *far* easier if you put it into a product that can handle the volumes much better.
  • by Tairan ( 167707 ) on Friday May 25, 2007 @05:07PM (#19275855) Homepage
    Someone need's to slap this author with large trout. There are many reasons NOT to use MySQL, of which this article touches on only one. For example:
    --Innodb scaling across multiple processors (MySQL bug ID 15815, still not completely fixed)
    --Limit of 1024 current transactions ( MySQL bug 26590)
    --Terrible performace when running MySQL Cluster
    --Single threaded mysqldump exporting and importing (recently fixed in 5.1)
    --Single threaded replication (making many changes? Don't count on it if you're running replication)
    --Poor handling of subselects
    --ineffecient ORDER by and GROUP BY
    --Poor quality filesort algortythm (want to see your $20,000 dollar database server die?)
    --better performance in 4.1.x

    Let's also mention that 5.1 has been out in beta for years now. When is it ever going to ship? MySQL now is proclaiming fixes in 5.2, and 5.1 isn't even on the board to ship yet.

    With all that, and more, I'm surprised this author could only come up with "it isn't made by Oracle" and "product mateurity."

    *disclosure -- yes, I play with MySQL databases all day long in large high use production environments. MySQL is great for small systems, but there -are- some problems when running on large enterprise grade systems. It'll get there
    • by iknownuttin ( 1099999 ) on Friday May 25, 2007 @05:20PM (#19276019)
      --Innodb scaling across multiple processors (MySQL bug ID 15815, still not completely fixed).....

      The audience for both articles are for IT (upper)mangers. Most of your argument above would be better off for the technical lead whose doing the report for his immediate manager (maybe technical) who'll then give a report to the CIO or even to a manger below him that would say:

      MySQL (GOOD)
      Oracle (GOOD but expensive)
      Excel (BAD)
      Not that those managers inherently stupid (hope not), it's just that their more concerned with the bigger picture and the resultant budget.

      • Re: (Score:2, Interesting)

        by Tairan ( 167707 )
        Yes, my arguments may be technical in nature, however the arguments in the article are worse than straw-man arguments. I'm surprised the author didn't mention that MySQL doesn't cost $20,000 per processor, therefor must be bad. Even given the intended audience (who, as you suggested, may not be extraordinarily technical) the pro-MySQL author did a much better job laying reasonable arguments.

        You mention Excel jokingly, but I know some companies which maintain large databases worth of information inside of
      • by oGMo ( 379 )
        PostgreSQL (AWESOME and FREE)

        And PHBs can spend budget on paid support.
    • --Poor quality filesort algortythm (want to see your $20,000 dollar database server die?)

      What does Al Gore have to do with this?
    • Doesn't seem odd to be complaining about the speed of mysql cluster when the pgcluster web site hasn't been updated since 2005?
  • Two of them are "The GPL can cause you problems."

    Two of them are "Product Maturity".

    And one is "Someone might think it's not scaleable". Possibly valid. Probably not.

  • It's almost impossible to say what the pros and cons are, when people usually stack or otherwise mix-n-match database products according to need. Even within the same organization, even within the same department, there will likely be servers that would benefit (if they're not already) and servers that would benefit from something else.

    And that's before you get into "which MySQL are we talking about anyway" debates. There are multiple configurations for how the tables are stored, for example. Then there's

  • If 1 and 2 are both valid reasons, then all RDBMSs are just as unacceptable for use depending on which of the two reasons fit the situaiton. For that matter, all software... everything... everyone!

    No seriously, I don't get it. Why is being under the GPL a bad thing?
  • by CodeMunch ( 95290 ) on Friday May 25, 2007 @05:25PM (#19276087) Homepage

    One trend I have observed but for which I have no hard data is that formally trained DBAs tend to prefer a proprietary RDBMS such as (most commonly) Oracle. I suspect that those with formal training and experience as a DBA (rather than as a software developer) tend to have a bias toward proprietary systems.

    Due to tue relative low incidents of formally trained Oracle DBA's being mauled by Tigers, you could also infer that formal Oracle DBA training will also protect you from Tiger attacks. (To re-use & mash up that old cliche).

    What a lame argument. Of course there may be some bias, but the fact is that: Oracle kicks every other RDBMS at pretty much everything: Stability, speed (optimizations up the wazoo), features, consistency.

    To be able to manage these systems efficiently & keep a "Q9" system up & running, the formal training certainly does help but I would argue is not required as the documentation is pretty damn helpful unless you get one of those wonderful ORA-600 errors (is that the magic "WTF" Oracle error? I can't recall).

    Sure - the woo of mega bux will entice many into Oracle DBA training but the weaker resources fall off quickly. You can't fake it when your production system is down.


    • Re: (Score:3, Interesting)

      by drinkypoo ( 153816 )

      Oracle kicks every other RDBMS at pretty much everything: Stability, speed (optimizations up the wazoo), features, consistency.

      Last time I checked, DB2 was more scalable than Oracle (less performance hit as you stuffed the database) and both Sybase and SQL Server were faster.

      • by dedazo ( 737510 ) on Friday May 25, 2007 @05:59PM (#19276483) Journal

        Last time I checked, DB2 was more scalable than Oracle

        That depends entirely on the platforms you happen to run them. DB2 on NT (what used to be called "UDB") is a joke; DB2 on OS/390 is pretty much what defines a "big-iron" database. Oracle on NT is nowhere near as good as it is on Solaris. But Sybase on NT is actually quite good - almost as good as SQL Server on the same hardware. Sybase 12.x on HP-UX is also quite good.

      • You are likely absolutely correct about DB2 - I've never had the pleasure of using it.

        In datawarehouse environments & app environments I've always seen more Oracle than SQL server. For speed/stability I've always had more success with Oracle but have no qualms with SQL Server - it is mighty fast and easy to use(ducks & dodges eggs & rotten tomatos) but I've queried sql server to a crawl more often than I ever have an Oracle db.

        We have an instance of Sybase where I'm at now but haven't given

    • What a lame argument. Of course there may be some bias, but the fact is that: Oracle kicks every other RDBMS at pretty much everything: Stability, speed (optimizations up the wazoo), features, consistency.

      And price.
  • Many applications need a small to medium size database that contains important but non mission-critical data. MySQL is perfect for those applications. No licensing hassles, no funds requests, no major administrative overhead. I don't have enough experience with MySQL to recommend it for a really critical database, but we do have plenty of need for smaller databases that we can set up quickly. I certainly don't see spending a lot of money on SQL Server (which we are doing) or any other big commercial server
    • by Shados ( 741919 )
      Thats a bit (but not completly) less true now than it was a few years ago. Most of the commercial databases now have free offerings and can be administrated by a child. If you're on Linux or something, then its nice, its probably just a command line away to install it and then its perfect, yes. On Windows however, might as well use SQL Server Express or something.
  • If you want to distribute the license for the database along with your own project, your project must either be licensed under a similar compliant license, or you must pay for a commercial license.

    This article comes from CIO website so I think that it if fair to say that they are most interested in applications for the enterprise. Enterprise applications don't bundle the database. They may require a certain database vendor product/version or a small set of database vendors but they don't bundle the database with the application. This is true whether or not you use SQL Server, DB2, Oracle, MySQL, or PostgreSQL.

    IANAL, but IMHO there is no legal restriction to selling a commercial, closed source application that requires MySQL as long as you don't include the MySQL application with it. This isn't a problem for enterprise applications because businesses that need such applications already have sufficient IT experience to run the vendor specific database that they are going to accept. If a company doesn't have sufficient IT experience to do this then they are going to have to go the SaaS route. Their are not going to be able to manage the application even if it did come bundled with a vendor specific database product.

    • Re: (Score:3, Insightful)

      by Evets ( 629327 )
      Agreed. Another point to be made is that many enterprise applications use the database layer as a storage mechanism and either don't optimize for the database platform or don't take full advantage of optimization capabilities on individual platforms.

      When it comes down to it, most enterprise apps would not see a significant performance shift in either direction based on platform and in those situations it is better to go with the database vendor with which your staff has the most experience. Enterprise app
    • IANAL, but IMHO there is no legal restriction to selling a commercial, closed source application that requires MySQL as long as you don't include the MySQL application with it.

      IIRC, the MySQL client library is as GPL as the server. There are exceptions for PHP (introduced when the GPL license change prompted PHP to move towards sqlite as their by-default database choice) but if you're writing an application in C++ and linking against the MySQL client libraries, you need to either use an ancient pre-GPL

  • I'm a little concerned about MySQL and the GPL... Here are some thoughts of mine about MySQL AB and the GPL: http://www.crownandcutlass.com/blog/2007/01/15/mys ql-ab-and-the-gpl/ [crownandcutlass.com]

    The link I have there for the MySQL internals doc seems to be invalid... It has moved to here: http://forge.mysql.com/wiki/MySQL_Internals_Client Server_Protocol#Licensing_Notice [mysql.com]

    Here is a quote:

    Because this is a GPL protocol, any product which uses it to connect to a MySQL server, or to emulate a MySQL server, or to interpos

    • by cortana ( 588495 )
      Unless the answers you get are transcripts from a court case, they will be meaningless.
    • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Saturday May 26, 2007 @12:05AM (#19279683) Homepage Journal

      Because this is a GPL protocol, any product which uses it to connect to a MySQL server, or to emulate a MySQL server, or to interpose between any client and server which uses the protocol, or for any similar purpose, is also bound by the GPL.

      Fiction: the protocol is GPLed. Frankly, that's just dumb; the GPL's scope doesn't include protocols.

      Fact: the MySQL client libraries are GPLed. If you use the official MySQL libraries and wish to distribute your program, your choices are to buy a commercial license or release your code under the GPL. I am unaware of any non-GPL client libraries for MySQL, although I've never had a reason to actually look for them.

      Basically, the author was mostly right, even if for the wrong reasons.

  • by BrandonReese ( 1055794 ) on Friday May 25, 2007 @06:00PM (#19276485)
    MySQL comes prepared to support all the most popular Web 2.0-ish languages, such as Ruby, Ajax and, of course, PHP.

    I've got the php_mysql.so library, but I can't seem to find the MySQL library in my Ajax installation... Oh wait, ajax isn't a programming language. I'm sorry little things like that really get under my skin (e.g calling the CPU "the hard drive", "I've got the Internet on my computer", calling excel spreadsheets databases). In case the author of the article didn't know, postgreSQL also comes prepared to support Ruby, and PHP.

    I also didn't see where they listed phpmyadmin as a reason to use MySQL. Seems like they always use that as one of the reasons.
  • But some +5 commenter pointed out what the 8 points against were, and they sounded lame. Another commenter actually listed 8 real problems with MySQL. But no matter how you slice it, the biggest, baddest, most ass kicking websites on the planet* are powered by MySQL. So... uh... deal with the reality. MySQL isn't going away.

    * Google.
    * Yahoo.
    * Digg**.

    ** Yeh, I'm the Digg DBA.
    • by Shados ( 741919 )
      I wouldnt bet my soul on it, but I was under the impression Google mostly used MySQL for internal system uses, not for their actual customer facing services...
  • Seriously (Score:3, Insightful)

    by Vexorian ( 959249 ) on Friday May 25, 2007 @06:16PM (#19276699)
    For the article writer a product's maturity solely depends on its age.... *thumbs down* I wanted an interesting read and got this?
  • It was enough that on the 3rd or 4th page of the '8 reasons not to' article that they used the PHB acronym, but then explained it in parenthesis. *TWEEET* Gene police! Out of the pool!
  • by seebs ( 15766 ) on Friday May 25, 2007 @06:35PM (#19276941) Homepage
    I recently started looking into databases, and I asked a bunch of friends. All the experienced ones gave roughly the same advice: If you don't have time to read directions, just throw something together with MySQL. It'll be okay. PostgreSQL would be better.

    So I took the extra ten minutes, and I'm pretty happy.

    Every large site I know of that uses MySQL has had scaling problems of one sort or another under load, usually to do with trying to handle multiple writes to the database. At least a few people have simply swapped in PostgreSQL and seen problems disappear instantly. One friend did performance testing, where what he found was that MySQL was faster for small sets of clients, but that it slowed down faster, and that for largish N, he couldn't get it complete the test on the available hardware, but PostgreSQL just ran.

    Having set up both a few times now, and having debugged problems with both, there is simply no way I'd use MySQL given any choice at all. It runs, but it feels accreted rather than designed. I know, Cathedral and Bazaar and all that... But there are times when you really do want the feeling that someone considered something up front.
    • by BerntB ( 584621 )

      MySQL has had scaling problems [under load] with trying to handle multiple writes to the database.

      Was that with InnoDB too?

      (My only showstopping problem with either one is that PostgreSQL had bad support for sorting on different character sets on a table basis. Didn't even sort on spaces for many collations, iirc. Don't know if I did something wrong or if it is better in the last version.)

  • Why Not Use MySQL (Score:2, Insightful)

    by smist08 ( 1059006 )
    From my own experience one of the main problems is a misleading feature set. When you choose MySQL you then have to choose one of five or so ISAM packages for it to sit on. This is a problem since they all have difference features. Do you want the one that supports multi-user, the one that is fast or the one with transactioning. Personally I want all of those and can't get them. Then we had problems with a number of queries where we had the where clause specify fields in the primary index and the optimizer
  • Why NOT to use MySQL (Score:4, Informative)

    by buss_error ( 142273 ) on Friday May 25, 2007 @07:57PM (#19277919) Homepage Journal
    I find that Brent Toderash's comments tend toward a faint aroma of FUD, while Tina Gasperson didn't exactly hit a hole in one with two of her five comments. Brent's comments seem to be more of "It's open source, it's not open source", certification of training issues, and in general only one half assed comment about the technology itself, which even he doesn't pretend to offer supporting evidence for.

    Tina is dead bang on with the TCO commnet; We pay more for Oracle support than we pay two Certified DBA's.

    Brent's comment about "ignorance" of workers not knowing a company has a site license for propertiery systems is not a technology fault, but a management fault. That cannot be properly consider a fault of the technology.

    Seems to me to be a send up. A trial ballon to support a future brochure slick about why paying $$$ for an RDBMS makes sense and why something "Free" isn't. We all know that using open source isn't free unless you have unlimited staff time and don't count system administration costs against a particular project. Open Source CAN cost a lot more than a closed source system, but it's not something I've seen. I'm sure there are examples, I just don't know of any.

    There are also times when open source doesn't make sense. Like in situations of unlimited libility in case of failure. Take a nuke reactor. Say you use open source products to control that reactor, and it melts down because a pump failed to start, a valve was incorrectly closed, and humans didn't follow proceedures. Automatically, it's the fault of the open source product, obviously, because you were too cheap to go buy "good" software.

    Until the human race as a whole can value a gift freely given by a stranger, it won't grow much past it's current point.

  • MySQL Gotchas (Score:3, Informative)

    by sneakerfish ( 89743 ) on Friday May 25, 2007 @08:21PM (#19278171)
    This page has a list of MySQL gotchas

    http://sql-info.de/mysql/gotchas.html [sql-info.de]

    Some of my favorite are things where MyQL accepts values it shouldn't and it doesn't throw an error. For example you can insert a 0 into a date field, 30000000000 into an in column (it will just ignore the higher order bits.

    MySQL is OK for quick and dirty, but it will always be dirty. If you want MySQL to be decent:

    1) Set it up with InnoDB and make that the default table type. MyISAM should only be used for data warehouse tpye applications where you are doing a lot of IO and its OK for the DB to be down for hours while you recover your corrupted MyISAM tables.
    2) Set the strict sql mode in the my.cnf. I don't remember exactly what the parameter name is, but you want MyQL to throw an error if you throw stupid values at it. Otherwise it will accept wacky values and you'll end up debugging it later.
    3) Set the default character set to UTF-8 if you can. This can be a bear but its worth it to be able to handle foreign characters.
    4) Avoid the fancy "features" if you can. The old features still have unresolved bugs and it isn't going to get any better with more and more storage engines going in.
    5) Monitor the performance constantly and be prepared to partition your data. Scale out isn't always as easy as it sounds.
  • I've RTFA, and I got to say it is complete crap. OK, actually I only read the first page, and the reasons I read aren't convincing enough. Beside I dislike websites that make you go trough 8 pages at one paragraph each of content only to get lost in their completely cluttered up design and in your face advertising.
  • well then (Score:3, Funny)

    by illuminatedwax ( 537131 ) <stdrange@alumni.uchic a g o . edu> on Friday May 25, 2007 @11:24PM (#19279427) Journal
    8 is more than 5!! Looks like I won't be using MySQL!

Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off.