Slashdot Mirror

← Back to Stories (view on slashdot.org)

MySQL AB Calls v4.1.7 Production Ready

Posted by timothy on from the world's-fastest-recipe-book dept.

puppetman writes "MySQL announced a few hours ago that 4.1 has been deemed production ready with the release of 4.1.7. The major enhancements of 4.1 include sub-selects, faster communication between client and server (thanks to parameter binding), replication over SSL, and lots more. A full list can be found here. Time to rehash those tired arguments about why MySQL is not a real database, and (Postgres/Oracle/SQL Server/Access/SAPDB/Ingres/etc) is the only real database out there."

6 of 59 comments (clear)

  1. Re:Production ready? by zatz · · Score: 4, Informative

    Sure, just use the InnoDB storage engine.

    --

    Java: the COBOL of the new millenium.
  2. Re:How to you pronouce MySQL by sethadam1 · · Score: 2, Informative

    I remember a long time ago they actually told you how to pronounce it on their website.

    Axtually, that was Postgres.

  3. Re:MySQL by zatz · · Score: 3, Informative

    MySQL is not suitable for complex queries.

    Actually, with the new support for derived tables in 4.1, it's as good as any other database product I have used (Informix, MSSQL/Sybase, Postgres). I have a production system which generates large, hairy SELECT statements (I've encountered MySQL's internal limit of 61 tables in a single join, to give you some idea how awful these can be) and runs them on a database with millions of records. It's quite fast (with appropriate choice of indexes) and implements all the SQL-92 features I expect, although the table-level locking of MyISAM is unfortunate.

    If you want to bash MySQL, it has plenty of real weak spots, eg transactions and stored procedures. But if you are going to run messy queries on big piles of read-mostly data, it's brilliant.

    --

    Java: the COBOL of the new millenium.
  4. Greater than 20, less than 99 by ttfkam · · Score: 4, Informative
    • Schemas
    • Views
    • Rules
    • Check constraints
    • Domains
    • Triggers
    • Custom datatypes
    • Stored procedures in no less than five different programming languages
    • Geometric/spatial datatypes and indexes
    • Real type safety
    • Errors when the alternative is data corruption
    • No silent failures
    • Enforcing a difference between NOT NULL and DEFAULT directives
    • Consistent foreign key enforcement (Target table must also be InnoDB, ON UPDATE does not allow recursive updates on the same table, out of range violations, brain dead implementation of NO ACTION)
    • Better transition to Oracle (closer feature parity)
    • Substandard transaction support (The time required to roll back a transaction increases in proportion with the number of operations performed during that transaction; Any non-InnoDB tables referenced in the transaction will not rollback)
    And have they fixed the bug where CREATE INDEX, DROP INDEX, and most ALTER TABLEs rebuild the whole InnoDB table? It's been a year.

    And how about bugs like this (http://bugs.mysql.com/bug.php?id=5670) where creating an index destroys the table. Nice.

    --

    - I don't need to go outside, my CRT tan'll do me just fine.
  5. Re:Have its developers' attitudes changed? by ttfkam · · Score: 4, Informative
    Does Postgres still make really bad optimizer choices if the data-types being compared aren't identical? Last I checked.
    At least there's a workaround. You can always explicitly cast your value to the type in question. I don't know of any similarly straightforward workarounds for the data manipulation/loss bugs in MySQL.
    --

    - I don't need to go outside, my CRT tan'll do me just fine.
  6. MySQL default installation by zaqattack911 · · Score: 2, Informative

    Does mysql still by default install and run "network enabled" with default admin passwords set?

    Someone at work tried it once and they got hacked in one day :)

    Love ,
    Zaq