Slashdot Mirror

← Back to Stories (view on slashdot.org)

MySQL Moves to Prime Time

Posted by ScuttleMonkey on from the can't-beat-the-real-thing dept.

MagLev writes "MySQL, especially version 5.0, is popping up on the radar screens of database gurus who built their reputations and book sales using other SQL databases. Ken North, who did those ODBC performance benchmarks for Oracle, Sybase, and DB2, wrote a recent article about MySQL 5.0. The article profiles mission critical database software and discusses how well MySQL 5.0 fits the profile. It gives good marks to MySQL, except for Java and XML integration."

35 of 261 comments (clear)

  1. So, uh by Anonymous Coward · · Score: 4, Funny

    What time and what channel?

  2. Really? by Sheetrock · · Score: 5, Funny

    I might have to check it out then -- thanks for the info.

    --

    Try not. Do or do not, there is no try.
    -- Dr. Spock, stardate 2822-3.




  3. Slowly But Surely by oirtemed · · Score: 4, Interesting

    OSS can compete with commercial offerings, it just usually takes more time to mature. Now, I'd expect to see a burgeoning market for MySQL support companies or companies offering database services and supports based on customized OSS MySQL sources. I use MySQL for websites and such, it's a great little database but I had no idea how much it scaled: MySQL has a demonstrated capacity for managing very large databases. Mytrix, Inc. maintains an extensive collection of Internet statistics in a one terabyte (1 TB) data warehouse that contains 20 billion rows of data. Sabre Holdings runs the oldest and largest online travel reservation system. It replicates 10-60 gigabytes per day from its master database to a MySQL server farm. The MySQL databases are used to support a shopping application that can accommodate a million fare changes per day.

  4. Gosh by Mateo_LeFou · · Score: 4, Funny

    Might we see an end -- or at least pause -- in the constant "MySQL sucks"-oriented comments/blog entries/ etc?

    --
    My turnips listen for the soft cry of your love
    1. Re:Gosh by Osty · · Score: 5, Insightful

      That's retarded. The database shouldn't try to fix buggy code.

      You're absolutely right. The database should fail to accept bad data. Integrity doesn't mean that the database tries to make an educated guess about what you meant (MySQL does this, and its one of the many reasons why MySQL sucks). It means that the database isn't going to let you insert data if it's not correct. Take the simple case of a foreign key. Your application may be buggy and try to insert a value into a column with a foreign key constraint that doesn't exist in the referenced table. The database should fail your insert, not try to find the closest match to the value you were asking for, or let you insert the value anyway even though it violates the constraint.

      The people that defend MySQL's lack of features by saying that you can fix all of the problems in application code obviously do not know what they're doing when it comes to databases. They may truly be smart people, but as soon as they spout such nonsense you can be sure that any DBA that hears it will never take them seriously again.

    2. Re:Gosh by Michalson · · Score: 5, Insightful

      It's not that it sucks, it's that it just doesn't stack up.

      The added features of MySQL 5, if put into the context of the auto industry, would be like a car manufacturer announcing that some of their 2005 models would now come with airbags and anti-lock breaks. Yes, it shows improvement, and yes, it may plug some longstanding criticisms, but in the larger picture it still means that company is years behind everyone else.

      MySQL 5 would have been a great advancement to put it in serious technological competition with other databases...if it had been released in 1999 or 2000. The reality is that Postgre is in version 8 with serious Windows support, Oracle is at 10g with gobs of new features 1% of DBAs will use, and Microsoft is in the process of unleashing a major new version of SQL Server onto a world that has done it no wrong. MySQL has only managed to catchup to where the industry was 5 years ago. Everyone else has kept moving.

      Real DBA's don't like MySQL for the same reason real web developers don't like IE. They're both behind the times, fail to live up to standards (CSS/ACID), and only got to where they are because of aggressive bundling. IE is "popular" because it's preinstalled and thus used by the average joe who doesn't know any other "internet". MySQL has made sure it is sitting on every free and cheap LAxP host out there, resulting in droves of kiddie web developers whose experience involves a few web tutorial on PHP and MySQL being locked into its heavily proprietary interfaces and dodgy "optimizations".

    3. Re:Gosh by superpulpsicle · · Score: 3, Insightful

      There is a decent sized market out there where organizations don't need a complicated schema or fancy features. I have seen places where MySQL is heavily preferred due to speed and liteness.

      They just want to do your average query on a fairly large db, but do it fast, hella fast. They'd rather put MySQL on a fast proprietory filesystem. Stripe and load balance off some fast storage arrays. And just blast away.

    4. Re:Gosh by consumer · · Score: 4, Informative

      Fails to live up to ACID? MySQL has had ACID transactions for years now. If you didn't know this, you have no place commenting on MySQL at all. It has the same sort of MVCC transaction and locking support that PostgreSQL does, and has since version 3.23.

    5. Re:Gosh by kpharmer · · Score: 3, Informative

      > There is a decent sized market out there where organizations don't need a
      > complicated schema or fancy features.

      then they might want to check out sqllite: a simple and completely free database *without* bizarre integrity problems.

      > They just want to do your average query on a fairly large db, but do it fast,
      > hella fast. They'd rather put MySQL on a fast proprietory filesystem. Stripe
      > and load balance off some fast storage arrays. And just blast away.

      if they're blasting away with mysql, then they aren't doing much with the data:
        - no parallel query capability
        - no memory tuning
        - no partitioning
        - no optimizer sophistication

      In short, unless you've got extremely simple queries looking up small sets of rows - mysql is slow as a pig, and can't compete with the commercial products. Again, if you *know* what you're doing.

      And assuming that you're interested in data integrity and are using the innodb database, then postgresql is just as fast. Possibly *much* faster if you're writing moderately complex queries with 5 or more tables.

      The idea that mysql is fast is a myth that came from php kids playing with a database for the first time. Once you actually compare the products available today mysql has nothing going for it - except quite a lot of inexperienced fans. Which, I have to admit, is probably worth quite a bit.

    6. Re:Gosh by Osty · · Score: 5, Insightful

      However, as of 4.1 most of the connectors out there can convert the truncation warning into an exception,

      Wait a second. If that's a warning, it means that it went ahead and did it and warned you that it did so. If a connector translates that into an exception, how do you roll back what MySQL already did? Besides, since when is it the domain of the connection software to handle referential integrity constraints?

      5.0 has server modes of varying strictness and SQL standard compliance to solve the problem.

      What's the default, and why would I trust them? MySQL has already proven they don't care what you (the developer) want by doing stupid stuff like trying to set defaults when you don't want them, silently ignoring commands (like when you try to create an InnoDB table on a deployment of MySQL without InnoDB), etc. Given that, my assumption would be that the default of MySQL is not the stricter modes, and even if I did choose them they wouldn't be as strict as you would expect.

      I'm hardly a MySQL fanboy, but to say it 'sucks' is probably an overstatement.

      I'd call it a generous understatement, personally.

      There are plenty of operations out there that don't need the features or can't justify the cost of the proprietary systems

      Data and referential integrity is not a "feature", but a requirement (if it's not a requirement for you, you don't need a RDBMS). Other features may not be that important, but they're still nice to have for the one or two times you need them. PostgreSQL is free if price is a concern, and there are plenty of other free DBMSs with varying levels of functionality out there.

      Which really just leaves Postgres and MySQL - kind of a wash IMHO.

      Really? Postgres -- fully functional, powerful RDBMS that routinely competes with the Big Boys in terms of speed and features, but has a funky maintenance system (vacuum) and doesn't run natively on Windows. MySQL -- toy database propelled to stardom by open source fanaticism, notoriously unstable, its vaunted speed only applies to relatively small, simple datasets (let's hope you're not doing something crazy like a join!), with arrogant developers who tell their users that they don't need certain features ... right up until the point that they implement the feature and then pretend they never bad mouthed it (yes, that's right, the developers did say that you didn't need row-level locking and transactions because you could do everything you need with a table lock and some programmer "smarts"). Sounds like a wash to me.

      Historicaly it was a few more features & better transaction support vs. lightweight/larger community/easy to configure - but the two are rapidly converging.

      In comparison to Oracle, Postgres is trivially easy to configure. It also has a very large (but not as vocal as MySQL's) community, and it's not very heavyweight. If anything, MySQL is slowly converging towards Postgres, but it's doing so in a distinctly MySQL sort of way -- deny, deny, deny right up to the point you implement the feature. Because foreign keys will make you slow!

  5. What possibly could anyone have against MySQL? by dynooomite · · Score: 3, Funny

    I thought everyone was just in love with Java and XML?

    --
    Linux Friendly since, like awhile.
  6. Apparently not by Anonymous Coward · · Score: 3, Interesting

    'prime time' enough for Sun.

  7. New features by Spy+der+Mann · · Score: 5, Informative

    (for the lazy)

            * capacity for very large databases
            * stored procedures
            * triggers
            * named-updateable views
            * server-side cursors
            * type enhancements
            * standards-compliant metadata (INFORMATION_SCHEMA)
            * XA-style distributed transactions
            * hot backups.

    1. Re:New features by Michalson · · Score: 4, Informative

      Or more specifically ISO SQL-92, or any other SQL standard. Everyone else seems to be smart enough to be able to implement a well documented industry wide standard as their base. MySQL didn't even start supporting UNION until version 4.

  8. MySQL != SQL by SharpFang · · Score: 4, Interesting

    One thing you must remember about, when considering MySQL. It's a relational database, all right, but it doesn't really support SQL.
    It supports most of SQL syntax, so SQL gurus will find it easy to learn. Most of basic SQL stuff works. But more advanced constructs like nested queries are either unsupported or terribly unoptimal, and some SQL features are there just for compatiblity sake but shouldn't be used at all. Instead you should learn and use a bunch of MySQLisms that aren't found anywhere else and do the same thing, much better (faster, safer, bug-free). So if you have a database app and ponder what database to integrate it with, choosing MySQL means more than plain tweaks. It may mean deep hacks. MySQL is devilishly fast when it comes to simple queries. Few databases can beat it in this domain. But it comes with a cost, shortcuts taken prolonging/breaking many other tasks. So choosing MySQL is a dangerous choice - it's a lock-in.

    --
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    1. Re:MySQL != SQL by matt4077 · · Score: 4, Informative

      If MySQL supported only a subset of the SQL Standard (big IF since it does have stuff like nested queries, transactions, triggers etc now), thats the opposite of lock-in. Obviously, there is no harm in using only a subset of SQL and then moving to a different RDBMS. It's exactly the Oracles and Microsofts with their embrace & extend policy that makes it difficult to switch: Oracle has _every_ (well, most - not the excellent fulltext search) feature of MySQL, so there is no problem to switch.

      --
      Fleur de Sel
    2. Re:MySQL != SQL by vadim_t · · Score: 4, Insightful

      I share your dislike of mySQL, but database lock-in is nearly impossible to avoid.

      It can be done if you do something simple, like say, a forum, but for anything large, advanced features are incredibly useful, and will make sure you're dependent on that specific database.

      For instance, it's very desirable to have everything in a stored procedure. Not only this gives a performance benefit, but it also increases security. Building your database this way you can ensure that nobody will ever be able to insert bad data. But the price of that is that converting to a different DB will be really difficult.

    3. Re:MySQL != SQL by Sheetrock · · Score: 3, Informative
      Bringing advanced SQL queries into MySQL and moving advanced (My)SQL queries out of MySQL.

      In both cases, you want to look before you leap. Do some trials to see how long porting will take before giving a time estimate, test the new system thoroughly (although that's recommended practice for switching RDBs anyway).

      That's not to say MySQL is the only platform where you risk lock-in. Database triggers can be hooked to implementation-specific things, for example. Unfortunately as with programming there are trade-offs to be made between optimization and portability and if you're pushing lots of tuples you opt for the former.

      --

      Try not. Do or do not, there is no try.
      -- Dr. Spock, stardate 2822-3.




  9. We chose Postgresql by Ritz_Just_Ritz · · Score: 5, Interesting

    I'm mostly just the digital plumber in my firm, but about a year and a half ago we were in a situation where it was time to migrate our production servers off of SQL Server 7 to "something else." The "something else" needed to be Linux friendly since we were phasing out M$ in our production environment in general. So we hired 2 former Oracle employees and expected them to tell us that Oracle was the answer. After about a month of nosing through our existing code, we were given a menu of options with their preference being postgresql. Mysql didn't make the cut because it lacked "important features" and wasn't "sql compliant", lacked "triggers", and something about "locking" which escapes me at the moment. I don't know a database from a hole in the ground, but that was our experience. We've been using Postgresql with RHEL 3 and RHEL 4 without incident. Very good for us...not so good for Mr. Ellison and Mr. Gates. Cheers,

    1. Re:We chose Postgresql by vadim_t · · Score: 5, Insightful

      It was a very good decision.

      Triggers are queries that are run automatically when the associated table or view is changed. It's generally considered to be a bad practice to overuse them, but they have a few very nice uses.

      One is implementing complicated checks. You can make an update query fail if any fields don't meet arbitrary requirements. That's good because you can use that to ensure that everything inserted in the database makes sense.

      Another is logging. You can easily make a trigger that inserts the previous content of a row into a different table. Can come really handy for debugging, or when you simply want to easily make sure any changes to some data can be tracked. Also handy if you not only want to deny access to something, but also record somewhere that somebody tried to touch it.

      Another use can be gradual redesign. If you're phasing out a column, you can do it in steps: Removing its usage from the latest version of your DB interface, and adding a trigger that ensures it has some value that doesn't confuse older versions. This can be used to provide smoother upgrades.

      Locking is a major problem. In a database locks must be placed on data to maintain the consistency. You definitely don't want a database that locks the whole table without a really good reason, because as soon as table locks start happening, your performance goes to hell, as everything else will have to wait.

  10. Re:Interesting by Haydn+Fenton · · Score: 4, Funny
    That, sir, is one of the most pathetic attempts at an above-0-scoring first post I have ever seen. Did you get that out of a Learn First Posts in 21 Days textbook?

    Chapter 3. Ambiguous Comments
    As discussed in the previous chapters, gaining a first post can be a difficult task in itself, let alone scoring something above -1, Offtopic. For this reason, it is often advisable to post something relevant to make sure your first post is visible to all who read the comments. This can lead to several problems, namely having to actually read the arti... er.. I mean, having to type a relevant comment quickly enough to beat another first-poster. For this very reason, we have provided a list of easy to use copy and paste ambiguous comments that will slide past your average moderator. Below is a short list of comments, guaranteed to keep your FP above 0. Write them down, learn them off by heart, and most importantly, keep them in your clipboard or in a notepad window so you're ready to paste and post as soon as your NST (New Story Checker© - Provided on CD) alerts you to a new post.

    • The article looks pretty good, I haven't read all of it, but it seems to point out some some good points about the product.
    • I am pleasantly surprised at the developments made in this area in the past few years, looks like before we know it we'll have flying cars, flying toasters and Duke Nukem Forever.
    • Looks like the server is getting sluggish already, why don't the editors just use coral links instead?
    • Oh come on, this is just getting stupid, how many more slashvertisements am I going to see today?
    • This story is a duplicate, it was posted around 2 months ago, does anybody have the link?

    I'm sure you can think of many more.

    In the next chapters we will cover the popular slashdot jokes guaranteed to get you those 5, Funny scores to impress your friends, and the best way to change your signatures to GNAA related text once your posts reach 5.
  11. Re:I can think of a pretty big plus in the column. by ProfaneBaby · · Score: 4, Informative

    Postgres is Free, MySQL is tied to a silly dual license (viral GPL and commercial), neither of which is as Free as the 3-clause BSD.

    --
    Video Phone Blogs send video messages straight to the web.
  12. innodb and fulltext? by allanw · · Score: 4, Interesting

    Can you use transactions, and have referential integrity and fulltext indexing on the same table yet?

    1. Re:innodb and fulltext? by jaiyen · · Score: 3, Informative

      Not yet apparently, according to http://www.innodb.com/todo.php, but at least it looks like progress is being made.

      In progress: Add FULLTEXT indexes on InnoDB tables. A sponsor for this project has been found, and a developer has been hired. Appears probably in 2006.

  13. Liked it, but don't use it anymore by nighty5 · · Score: 4, Interesting

    I used to love MySQL back in the hayday, but then they changed their license model, thus it was "good night sweet prince".

    Most other decent databases use something similar to LGPL for use of their libraries, thus there is no need to disclose your source code in an application that uses the database. This is rather a critical feature identified by almost all database vendors. Even Microsoft SQL has an LGPL-like license that doesnt mean you have to share your code.

    Once MySQL was reaching critical mass, they decided to change the rules and restrict the license. PHP and others revolted and dumped MySQL for SQLite as the default database for PHP 5. Some could argue it was due to library mixup hell, with multiple versions of libraries on the system, but we all know the main reason was behind the license.

    MySQL got a bit scared and made this silly license exception to the top 20 FOSS projects (don't quote me on that, recalled from memory) so they could be LPGL.

    In the process I moved all my code to PostgreSQL and havent looked back.

    1. Re:Liked it, but don't use it anymore by sloanster · · Score: 3, Insightful

      Oh well, freeloaders get bitter when the free ride ends - or when they think it might end? or maybe they don't like the license for some reason? (I guess I'm not sure what the issue is, but I digress)

      I use mysql and love it. Not only are the availability and price unbeatable (it ships with my OS, how much easier could it get?) but the performance is truly outstanding. Predictably though, the mysql-bashers who are stuck in 1998 will arise to tell us how mysql can't do subqueries, or has no transactional integrity, or whatever other fairy tales they might dig up at random

      Why can't we just admit that mysql is a useful tool in many situations, and move on?

    2. Re:Liked it, but don't use it anymore by Just+Some+Guy · · Score: 4, Informative
      SQLite has no advertising clause. postgresql does.

      I call your bluff. Here's the entire, unedited PostgreSQL license (source their website):

      PostgreSQL Database Management System (formerly known as Postgres, then as Postgres95)

      Portions Copyright (c) 1996-2005, The PostgreSQL Global Development Group

      Portions Copyright (c) 1994, The Regents of the University of California

      Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.

      IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

      THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

      Where's this advertising clause you speak of? Or did you hear "BSD license" and drag out a decade-old complaint that's long since been addressed? That's as bad as people complaining that MySQL doesn't support transactions, except that's true under certain circumstances whereas your criticism is completely unfounded.

      --
      Dewey, what part of this looks like authorities should be involved?
  14. Re:I can think of a pretty big plus in the column. by Anonymous Coward · · Score: 3, Informative

    If you're just downloading and using the software, BSD and GPL are *identical* (because you can ignore them both). Talk about how un-relational MySQL is, or how it gets in the way of a DBMS' fundamental purpose (data integrity) with it's bizarre misfeatures, but don't spread FUD about the GPL. 'kay?

  15. 3 words... by ninja_assault_kitten · · Score: 3, Insightful

    FULL OUTER JOIN

  16. propaganda by kpharmer · · Score: 4, Insightful

    I've read the article, am familiar with the product, and am also familiar with data warehousing. This is just propaganda.

    > MySQL has a demonstrated capacity for managing very large databases. Mytrix,
    > Inc. maintains an extensive collection of Internet statistics in a one
    > terabyte (1 TB) data warehouse that contains 20 billion rows of data.

    MySQL is a horrible product for warehousing: no query parallelism, no partitioning, primitive memory management, primitive optimizer, etc, etc. 20 Billion rows in a single table? What would mysql do with that? Any typical warehousing queries would take hours to come back. More likely either the database owners are just logging data someplace cheap, or they are creating hundreds of much smaller tables.

    > It replicates 10-60 gigabytes per day from its master database to a MySQL server farm.

    Ah, a 'server farm'. So, the 20 billion rows are probably spread across dozens of mysql servers. This explains it all. Even SQL Server can do better than that.

    > The MySQL databases are used to support a shopping application that can accommodate a million fare changes per day.

    Yeah, I think db2's most recent benchmark was for something like 3 million transactions a minute.

    This is little more than an advertisement for mysql. A little poking around would probably show that he's on the mysql payroll.

    1. Re:propaganda by mattcasters · · Score: 5, Interesting

      Sure, how about comparing MySQL to other free & open-source databases.
      PostgreSQL, Firebird, MaxDB and Ingres all handle the milions of rows *a lot* better.
      Especially PostgreSQL seems to stay on par with Oracle, even offering (primitive) support for table partitioning, bitmap indexes etc.

      If I would try to do data warehousing on an open source database, it's probably going to be PostgreSQL.

      --
      News about the Kettle Open Source project: on my blog
    2. Re:propaganda by kpharmer · · Score: 3, Insightful

      > As for me, I'm happy that in spite of taking minutes, it's giving me the
      > correct answer. That's all I need and I don't think it's fair to directly
      > compare MySQL to a $20,000 database. Of course it won't perform as good.
      > It's like comparing a Toyota to a Ferrari and complaining that the Toyota
      > won't go as fast.

      Sure - if it only takes a few minutes every now and then that might not be a big deal.

      But regarding the cost of the alternatives:
          - postgresql is freer (no way of having to face $600/year charges as with mysql), and has a better optimizer.
          - oracle is only around $1-2k for a small footprint database. this wouldn't
              include partitioning, but at least you'd get a smarter optimizer.
          - db2 is around $700 for a 2-way server. this would provide partitioning
              (via mdc or union-all views), parallelism, and a better optimizer.
          - sqllite is freer (again, no cost), and I suspect has a better optimizer.

      So, for $700 once, plus maintenance (18%/year?) you'd have a vastly faster product than MySQL - which can cost you $600/year. And you don't need to talk to a lawyer to figure out whether or not you need to pay for mysql. Or you could get other products that are faster with complex queries and are completely free.

  17. not Postgres by cpeterso · · Score: 4, Informative


    Actually, "Postgres" is was a precursor to "PostgreSQL". The database started as a university research project called Ingress. A follow-on version was called Postgres (i.e., Post-Ingress). SQL support was added later; thus PostgreSQL (Postgres + SQL).

    --
    cpeterso
  18. I think not by vandan · · Score: 3, Interesting
    MySQL are finally bringing stored procedures, views and triggers to their database server. Cool. I've been using MySQL for 6 years now, and I've very happy with the version I'm currently running ( 4.0.25 ).

    Having said that, anyone who says that MySQL are ready for 'prime time' are clearly deluded. You can have a database server with unbelievable speed, features, security and stability, and it doesn't mean a damned thing if you don't have client libraries ready.

    MySQL's client libraries are appauling. MyODBC, their ODBC connector, has been one big fuckup after another for the past 2 years. It's a minefield of:
    don't use this with that, and certainly don't download this one - we don't know what we were smoking when we released that

    Rock up to a MySQL mailing list, and the most common questions is about client libraries and the 'new' authentication system. The problem is that this authentication system is no longer new - it's old. It's many years old. Why haven't the client libraries been updated? The error message suggests that users "upgrade their client libraries", but upgrade to WHAT? Perhaps the error should read:
    You are using client libraries from last century. Perhaps you should match them with a server product from last century. Please don't use our newer server products until we have managed to release some client libraries to match

    I for one would prefer to see some actual client-side support for 4.1.x before people start declaring 5.0.x 'ready for prime time'. You can't use 5.0.x features with 4.0.x libraries.

    Has anyone checked out the GUI admin tools? These are also a long chain of distasters. MySQL seem to spend 18 months getting a GUI looking promising, if a little buggy, and then abandon the project. What happened to mysqlcc? What's happening with Administrator / Query Browser? Critical bugs reported months ago have gone completely untouched. For example, you can't edit tables with a primary key, because Administrator doesn't recognise the primary key, and strips it out of the table when you click 'apply'. Cool! Sounds ready for prime time to me! When will MySQL add support for primary keys to their products?

    Yes, I'm stirring here. But none of the above is in the slightest untrue. MySQL have lost their focus. With so much attention being paid to a 5.0.x release, everything else is suffering badly.
  19. From personal expereince... by g_lightyear · · Score: 4, Interesting

    26 million rows = broken MySQL system.

    It just doesn't cope. It's fine if you've got no data to speak of; it's great when the sizes of what it's working with is small.

    IT TAKES 24 HOURS OF UNWRITABILITY TO MAKE A DAMN BACKUP, FOLKS.

    MySQL was the biggest mistake I ever made. I had the option of choosing Postgres on an older version of the software, or MySQL on the latest, and I've been regretting it ever since.

    The fact is this: I've used it for stuff when the amounts of data are small, and it's brilliant - but if you need to keep a lot of information, you're screwed - run, don't walk, to the nearest vendor and get something decent, because MySQL just can't cut it. It's missing too much in too many places.

    Now, I haven't used 5. I'll have to, because 4 sucks, and 5 can't be worse - I can only hope that 5 gets rid of the worst of my problems; it will probably stay slow and unresponsive, and continue to take an hour to generate a report, but I can at least pray that perhaps, if I'm lucky, I can get a backup out of it without taking down the system.

    No matter how good you think it is; no matter how fast you think it might be... don't pretend it scales up to the kinds of loads the commercial vendors can handle. There's a reason the big boys cost big money, and despite popular opinion, it's not all just leeching money out of your pocket. MySQL doesn't do big well.

    --
    -- A mind is a terrible thing.