Slashdot Mirror


MySQL 4 Declared Production-Ready

Simprini writes "After absolute ages of testing MySQL 4.0.x in various versions of BETA through GAMMA it looks like MySQL AB finally released MySQL 4.0.12 as ready for prime-time production use. I know my company has been waiting for a long time for this because our customers absolutely refused to use beta releases of this product. Query caching here we come."

5 of 329 comments (clear)

  1. Waiting for maturity by acostin · · Score: 5, Interesting

    We are also using MySQL for many web projects, but to create a complex CMS the future features in MySQL (that also exist in other current database systems - like postgreSQL and probably others) are needed.

    We have initially created Komplete - http://komplete.interakt.ro/ only for PostgreSQL, and our users attitude indicated us that MySQL should have been supported. So we are releasing now the Komplete Lite version (GPL), for MySQL - but it's a real pain to simulate subselects, real unions (emulated with temporary tables now), cascaded deletes and stored procedures.

    The speed is quite similar, but PostgreSQL is still much better for complex web applications.

  2. Woho! by Dri · · Score: 5, Interesting

    I work at at the tech development dept. of a major car company and this is great news. We are finally able to throw MySQL onto production servers and give Oracle the boot for small RAD webapps.

    What I've heard from MySQL officials in person is that MySQL 5.0 is set to be released late Q4 this year. Then stored procedures, sub selects (4.1) and constraints should be ready for primetime, then we talk real heavy enterprise applications. Hope they keep the schedule! =)

    Well, Monty and the rest, Good Job! Keep it up!

    --
    Girls are strange. They don't come with a man page.
    -- Michael Mattsson
  3. Apparently 90% don't need those features.......yet by JohnDenver · · Score: 5, Interesting

    What about integrity constraints, foreign keys, interval datatypes, full outer joins, subqueries, set operations, VIEWS for god's sake, and triggers? Too hard?

    For cryin' out loud, half of these missing features put the "relational" in "relational database"!


    First of all, kudos to the MySQL team for atleast getting as far as they have. Just because I'm not fond of thier product, doesn't mean they don't deserve credit.

    I've been banging my head a little on this one too trying to figure out why so many people are pushing MySQL and not something stable and complete like PostgreSQL? After all, PostgreSQL has triggers, stored-procedures, functions, referential integrity, and tons of other features to make your life easier. You may not need all of these features now, but can you honestly say your app won't expand and require advanced features?

    Is it the MySQL marketing engine? Does PostgreSQL sound intimidating? Are there actually technical advantages that MySQL have over PostgreSQL? If so, what are they?

    The most common argument I've heard in defense of MySQLs lack of basic features is: "It's good enough for 90% of the problems out there." However, everytime they implement a basic feature that every other RDBMS has had for decades (like UNION), people respond as if MySQL is getting close to be taken seriously.

    Secondly, In my experience, I've found that 90% of the applications I've worked on end up using those advanced features sooner or later. Those features usually save a tremendous amount of time I would have otherwise had to spend writing code to make my database jump through hoops. In addition to saving time, there a lot of features which simply allow me to make my applications more useful or intuitive to the end user, which is the whole point.

    Am I missing something here, or is the Emperor not wearing any clothes?

    --
    "Communism is like having one [local] phone company " - Lenny Bruce
  4. MySQL 4 is good by chrysalis · · Score: 5, Interesting

    I've been extensively using MySQL 4 for over one year on very loaded production systems.

    It has actually always been faster and more solid than the 3.23.x series.

    I only had some small issues with InnoDB (the same issues were in 3.23.x as well). But the InnoDB maintainer, Heiki Turri, is someone that really cares about bug reports. All reported bugs were immediately fixed.

    The query cache is efficient, and the fulltext indexing was greatly enhanced (if only it worked with InnoDB tables...) .

    I've not installed any 3.23.x version for a while, and I'll never go back.

    Probably a lot of system administrators will wait. They will read that MySQL AB blessed 4.x as production-ready, but they will wait, as if it was an 1.0 version that still needs some maturity.

    It's not. MySQL 4.x has already received a lot of testing, and it is already being used on large production sites. Just read the MySQL mailing-lists.

    Upgrading from MySQL 3.x is also easy. You only need to run a little script to upgrade the grant tables (and even if you don't, everything will work). No need to export/reimport the databases. So upgrading is straight forward.

    --
    {{.sig}}
  5. Re:Apparently 90% don't need those features....... by Trifthen · · Score: 5, Interesting

    We run postgres and we're doing our damndest to get rid of it. We have some databases that get 50-100% data turnover rate daily, making hourly vacuums essential to not having the Ever Expanding Database problem. Not to mention that vacuum doesn't clean up indexes, so you'll also have to re-index periodically if you don't want those to grow to thousands of times their optimal size.

    I should probably say that such reindexes require full table locks, so you could get contention issues under heavy load when reindexing your database. Mysql gets by this by making indexes in a temporary space, and switching when the index is done. This means I can select from a table, with full benefit of an existing index, even while I change an index, or even redo the index. Not that I have to... mysql doesn't require vacuum or reindex to avoid continuous linear bloat.

    So... we don't like having to babysit our database to get good performance out of it. We're willing to work around lack of foreign keys to avoid having to do full database import/exports on a weekly basis, and multiple hourly cron jobs to make sure we don't randomly fill our disks. Faster? Slower? Who cares. Postgres is just too annoying to use in production.

    --
    Read: Rabbit Rue - Free serial nove