Slashdot Mirror


MySQL 5.0 Candidate Released

Brian "Krow" Aker (Former Slashdot Coder now MySQL Employee) writes "I am pleased to announce the release candidate for MySQL 5.0. This version has been in development now for three years. We have worked to add update-able views, ansi stored procedures, and triggers. In addition we have added a number of fun features that we are experimenting with and resolved issues with bad data inserts (which personally annoyed the hell out of me when we rewrote Slashdot a couple of years back so I am happy to see this issue go away). We look forward to feedback on the candidate and will show some love for bug reports."

38 of 339 comments (clear)

  1. Time for new comparisons to be made. by CyricZ · · Score: 4, Interesting

    It's time for somebody to do a new, impartial study regarding the performance and feature benefits of this new release of MySQL, PostgreSQL, Firebird, SQLite, and perhaps other open-sourced relational databases.

    --
    Cyric Zndovzny at your service.
    1. Re:Time for new comparisons to be made. by tdemark · · Score: 5, Interesting

      And of course you can't include Oracle in any impartial study.

      You could, except for the fact that the license you just paid thousands per CPU for doesn't allow you to publish the results.

    2. Re:Time for new comparisons to be made. by ceeam · · Score: 3, Interesting

      But puhhhlease, don't put MySQL performance based on MyISAM and feature set based on InnoDB! Stick to either one. BTW - last I checked for myself, Firebird was beating _even_ MyISAM for raw speed on simple queries for local engine. Something I did not expect. Oh, yeah! When comparing performance please include results for local engine AND over-the-LAN performance. Different beasts have different protocol issues that show up when using "real" LAN and may be masked when using "local" engine mode. For example, MySQL has very simple and LAN-friendly protocol. Unlike Firebird, but it's still ok. And MSSQL, EG, has very, very serious issues when used for lots of "simple" queries.

    3. Re:Time for new comparisons to be made. by ajs · · Score: 4, Informative
      From the linked article,
      "The standard Oracle license agreement normally prevents users from publishing benchmark results." -http://www.orafaq.com/faqora.htm#SPEED
      Clear enough?
  2. Is it a "real" database yet? by digidave · · Score: 4, Interesting

    Every time any database is mentioned on Slashdot we get a load of comments about how MySQL is not a "real" database because it doesn't support {insert random feature here}.

    Is it a real database yet?

    --
    The global economy is a great thing until you feel it locally.
    1. Re:Is it a "real" database yet? by mmkkbb · · Score: 3, Informative

      Actually, most of those features are in MySQL 4. The two big problems are: Lots of people still run MySQL 3.x, and these features only work for certain table types.

      --
      -mkb
    2. Re:Is it a "real" database yet? by codesurfer · · Score: 5, Interesting

      I'd say so...despite the detractors, I've been able to use MySQL for many highly trafficed sites, and heavily used applications. Does it have the full robustness of Oracle? Of course not, but it also does not come with the accompanying price tag. Choice of db software is just that...a choice. I can envisage situations in which I may prefer having Oracle, but to be honest, MySQL addresses most day to day situations more than adequately. It's a real db, IMO.

    3. Re:Is it a "real" database yet? by LLuthor · · Score: 3, Insightful

      MySQL selects do not use indexes when there are sub-selects most of the time. This makes them practically useless unless you can re-factor the query to use a convoluted join instead.

      Sub-selects suck in mysql compared to postgresql or oracle. I havent used other DBs much so I don't know how well they perform.

      --
      LL
    4. Re:Is it a "real" database yet? by Anonymous Coward · · Score: 3, Insightful

      I cannot trust MySQL to store data reliably until the MySQL give a clear explanation as to why they made decisions that no competent database developer would ever make.

      For example, you have a constraint limiting a column to a maximum of 99. You attempt to enter 999 as a value, and it got silently altered to 99. Not only is it against SQL standards, it's also completely and utterly the opposite of common sense.

      Just once, I'd like to hear a MySQL developer say "yeah, I don't know what we were thinking, that's a really fucked up thing to do". It doesn't matter whether this intentional bug got fixed, what matters is that there are MySQL developers that thought that this was a reasonable thing to do.

      That's not an isolated incident, either. There are reams and reams of utter idiocy along exactly those lines. So really, what would it matter if they've fixed those particular instances? How do I know they haven't introduced a dozen more breakages along those lines? So far, they haven't shown any indication that they even realise how fucked up that is - so why on earth would I trust them with data that matters?

  3. Re:Anyone know of a good free MySQL GUI? by Chagrin · · Score: 3, Informative

    Use the MyODBC driver. Link the tables with Access and cut and paste all you want.

    --

    I/O Error G-17: Aborting Installation

  4. Examine t he license carefully!! by scorp1us · · Score: 5, Informative
    After the 3.x series, the license changed drastically. Of course you won't find this discussed much. The permitted uses of MySQL as GPL are significantly reduced. You can only use MySQL in conjuction with OSS. Previously, you could use MySQL in a non-GPL environment under several permissive conditions. The new license is so restrictive now that a special exception is made for PHP

    Specifically:

            * MySQL is free use for those who are 100% GPL. If your application is licensed under GPL or compatible OSI license approved by MySQL AB, you are free to ship any GPL software of MySQL AB with your application ('application' means any type of software application, system, tool or utility). You do not need a separate signed agreement with MySQL AB, because the GPL license is sufficient. We do, however, recommend you contact us as there usually are good opportunities for partnership and co-marketing.


            * Under the Open Source License, you must release the complete source code for the application that is built on MySQL. You do not need to release the source code for components that are generally installed on the operating system on which your application runs, such as system header files or libraries.


            * Free use for those who never copy, modify or distribute. As long as you never distribute the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not.


            * You are allowed to modify MySQL Software source code any way you like as long as the distributed derivative work is licensed under the GPL as well.


            * You are allowed to copy MySQL binaries and source code, but when you do so, the copies will fall under the GPL license.


            * Optional GPL License Exception for PHP. As a special exception, MySQL AB gives permission to distribute derivative works that are formed with GPL-licensed MySQL software and with software licensed under version 3.0 of the PHP license. You must obey the GNU General Public License in all respects for all of the code used other than code licensed under version 3.0 of the PHP license.


            * FLOSS License Exception. We have created a license exception which enables Free/Libre and Open Source software ("FLOSS") to be able to include the GPL-licensed MySQL client libraries despite the fact that not all open source licenses are compatible with the GPL (this includes the PHP license version 3.0). Read more about the FLOSS License Exception.



    Considering the new license and still lacking features, there is little reason to use MySQL. Postgres has "all that anda bag of potato chips."

    --
    Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
    1. Re:Examine t he license carefully!! by Scarblac · · Score: 4, Interesting

      In short:

      • If you don't distribute MySQL, you're under no restriction whatsoever
      • If you do want to distribute, MySQL is GPL
      • Besides, MySQL goes out of their way to give you even more freedom to distribute it if you want to bundle it with stuff that has one of several incompatible licenses

      Sounds good to me!

      --
      I believe posters are recognized by their sig. So I made one.
    2. Re:Examine t he license carefully!! by T-Ranger · · Score: 3, Insightful
      Under the Open Source License, you must release the complete source code for the application that is built on MySQL

      Well, I suppose that is a question of semantics. I would say that if you take MySQL had hack it, relese it as BobSQL, then this applies - BobSQL is built with MySQL. If you write a recepie organizer that uses MySQL, then you need to do nothing.

      Read more about the FLOSS License Exception.

      What is the problem? MySQL has a client library, which is released under the GPL. Generaly, if you want to use and distribute MySQL client libraries, you also need to release whaterver is yours as GPL. If its commercial, you can always buy a license from MySQL AB. For other OSS project this may be unacceptable - and for PHP it was, for example. So provided that these other OSS projects conform to specific guidelines, they are free to distribute the client libs.

      You always, always, have the option of using MySQL in a non OSS enviroment. Buy a license.

      I cant see how their license plan could be any more friendly, unless they switch to a BSD style license. Want to just use it? Knock yourself out. Want to hack on it and continue to release it under the GPL? Knock yourself out. Want to release it with another, non-GPL, OSS license? Knock yourself out. Want to not release the source? Buy a license.

    3. Re:Examine t he license carefully!! by jadavis · · Score: 4, Insightful

      If you do want to distribute, MySQL is GPL

      The problem is that the client library is GPL, not LGPL as one might expect.

      That means that any application that you distribute that can access a MySQL database must be linked against the MySQL library, which is GPL, forcing your application to be GPL.

      Most people don't consider adding MySQL support to their application to be "distributing MySQL".

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
  5. Re:Anyone know of a good free MySQL GUI? by Anonymous Coward · · Score: 3, Informative

    Aqua Studio is very good (http://www.aquafold.com/) links to most different db types as well as standard ODBC

  6. MySQL 3 - MySQL 5 by Scoria · · Score: 3, Interesting

    I certainly have to give them credit for one thing. The MySQL developers have been subjected to some very harsh criticism over the years, but few would accuse them of ignoring it.

    It impresses me that they actually seem to be listening.

    --
    Do you like German cars?
  7. Re:How does the source code quality compare? by JohanV · · Score: 4, Informative

    How do you want it to compare?

    Source code quality is not easy to compare. At a first glance, MySQL is doing very good. They have this nice blurb about only having 1 defect in 4000 lines being more then 4 times better then with most commercial software. But if you dig deeper, you notice that PostgreSQL has been tested by the same company and only had 1 defect in every 39000 lines of code. Wow, so PostgreSQL must really be a lot better then MySQL.
    But if you dig even deeper, you will find some explanation from a PostgreSQL developer and you remember what your mother told you about lies, damned lies and statistics.

    You want to know about source code quality? Go read the source.

  8. I think you miss the point by Fished · · Score: 5, Informative
    The point is not whether MySQL is a "real" database. Clearly, it is a real database that is capable of doing real work.

    The point is that, even in recent versions, MySQL has some serious limitations that other OSS databases (e.g. PostgreSQL) do not suffer from, and no really significant corresponding advantages. MySQL was not designed from the ground up to be many things it is now trying to be--it was not designed to support transactions, it was not designed to support foreign keys, it was not designed to support stored procedures. It was initially conceived as a small, fast database for managing very large datasets in a warehousing sort of role. PostgreSQL, on the other hand, was always conceived of as being a heavier-duty database, and this shows in terms of feature completeness and SQL standard compliance.

    Given that the performance differential (which was always overstated) has been overcome, why would you want to go with MySQL only to discover what the latest feature to be missed was? What's the advantage to MySQL?

    --
    "He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
    1. Re:I think you miss the point by kpharmer · · Score: 3, Informative

      > InnoDB supports the features you mentioned, and that I quoted, so why is that less desireable than having the table handler builtin?

      Because it is core functionality.

      Having a separate product responsible for managing io may be one of the reasons that mysql's optimizer is so primitive - and may be a reason why they will struggle to improve it. Note: the optimizer is the component responsible for determination of how your joins will be performed under the covers - mysql is notorious for failing to use indexes it should, using indexes when it shouldn't, never using star-joins, five-way joins that day 10x as long as they would in any other database, etc.

      Perhaps it's also why views took forever to implement, and materialized views might take another forever.

      It's also perhaps the reason for all the inconsistencies in table creation.

      There are also benefits to using innodb - it has undoubtably speed up mysql's development by several years. Still, now it's a boat anchor that should be abandoned.

      > For me, the massive community is a big plus. A rich set of tools is another advantage.

      yep, although it may be the only advantage that mysql has, it's a huge one.

  9. Please stop the MySQL Bashing... by Anonymous Coward · · Score: 4, Informative

    Before all the MySQL bashing starts can we please stop and have an intelligent conversation? The bottom line is that MySQL works great! For all those people who say .. "ya its a kids toy" well look at some of the sites and companies that are using mysql.. "Friendster" , "The Friendfinder network" , "Yahoo!" .. These sites each have millions of active members and are running just fine. Where else can you load up a 50+ database cluster and not have to shell out a fortune on licensing fees? All the developer tools are great!!

    1. Re:Please stop the MySQL Bashing... by ad0le · · Score: 3, Insightful

      Where else can you load up a 50+ database cluster and not have to shell out a fortune on licensing fees?

      PostgreSQL

      --
      My mother never saw the irony in calling me a son-of-a-bitch.
    2. Re:Please stop the MySQL Bashing... by generalpf · · Score: 4, Interesting

      The MySQL guru at Yahoo! -- Jeremy Zawodny -- wrote an O'Reilly book on the different hacks and scrapes they needed to make MySQL perform properly. It's full of anecdotes of MySQL brainf**kery and whatnot. If you consider Yahoo! using MySQL to be an endorsement, try reading High Performance MySQL.

  10. What about those [MySQL] gotchas? by bogaboga · · Score: 3, Informative

    They have done very little about these MySQL gotchas! They should have eliminated most of them first. You can still read them here: http://sql-info.de/mysql/gotchas.html.

    1. Re:What about those [MySQL] gotchas? by minginqunt · · Score: 5, Informative

      No true.

      Those gotchas all (mostly) go away if you run MySQL 5.0 in strict mode. Compatibility mode is provided for 4.1 and back-asswards behaviour if you need it.

      See: http://dev.mysql.com/doc/mysql/en/server-sql-mode. html

      Martin

    2. Re:What about those [MySQL] gotchas? by robnauta · · Score: 3, Informative
      Of course, as the MySQL line has always been to manage transactions in code, I don't see why they didn't just raise an error and let the application deal with the manual rollback. Who would ever want invalid data to be inserted?

      Manual rollback ?The idea is that if you do the following:
      insert into mytable values (100);
      insert into mytable values (200);
      insert into mytable values (300);
      rollback;
      rolls back ALL changes. This is in Oracle, in Sybase or SQLServer you would start with a 'begin transaction'.
      Imagine these inserts are in an upgrade script for an application. Now the script has to either errorcheck and commit after each row, or have nested if-then's. If the second statement fails, delete 100, if the third one fails delete 100 and 200. And you have to do all that in SQL ? No thanks. Give me a REAL database.

  11. Re:Anyone know of a good free MySQL GUI? by JohnnyBigodes · · Score: 3, Informative

    Sorry about the "free" part, but Navicat is the best MySQL interface that I've seen to date, and I've tried quite a few (not all of them, obviously :)

  12. Re:Having worked with oracle 10i for the last year by kpharmer · · Score: 4, Insightful

    > And Oracle 7 for the two years before -- in a not-so-large database -- I think there is not much to fear...

    Actually, no: many databases these days are now supporting various types of logs - in which you've got tables with tens of millions of rows. Oracle and DB2 have the following in place to support massive tables:
    1. query parallelism - that provides linear performance improvements up to 4 cpus or so
    2. data partitioning - that allows the database to just scan data needed, rather than entire table when indexes aren't appropriate (b-tree indexes only work for around 1-3% of data)
    3. materialized views - in which views actually hold data - and this data is kept up to date by the database server. Often used for summary tables.
    3. query rewrite - in which your queries are automatically re-written to apply to a summary table (see materialized view) if one exists.
    4. clustering - in which data spans multiple servers, and all servers work together on your query.
    5. smart optimizer - intelligent score-based optimization responsible for determination of best access paths for your queries.

    With the above features db2 or oracle can drive 40x the performance of mysql or postgresql in a reporting application (or transaction one with a few large scan-oriented tables) on identical hardware (say a 4-way SMP). If you didn't see an impact from these features then either you have one of the fairly rare apps that can't benefit, or you should revist the design.

    Don't get me wrong - I really like postgresql. But neither it nor mysql is even in the ballpark for performance on db2 or oracle. Nor is the price much different - db2 is only around $700 for 4/5 of the above features on a 2-way smp vs $500 for mysql. Eventually mysql & postgresql will support these features. But it'll probably be five years before they are working well.

  13. And despite the fact that I feel postgres... by MrBandersnatch · · Score: 4, Interesting

    is often the better database solution, I'll still be using MySQL. Why? Well a quick search on cwjobs shows 188 jobs requiring MySQL experience vs 7 for postgres!! Its a real shame but having used the best tool (C++ Builder) for my last job and then being unemployed for @2 years because people wanted either VC++ or Unix based C++ experience; I *WONT* be making the same mistake again!

    Anyways, that said, Ive already played about with 5.011 and apart from the yukky syntax one has to use to support transactions it seems quite stable. Its might have taken a long time for them to finally make it a "real" database product but it seems good enough for small databases.

    One of my next jobs is to test it with 10 million + records and see how it performs though so my assessment may be premature...

  14. A database is not a GUI by msobkow · · Score: 4, Interesting

    The only so-called "database" that emphasizes it's GUI is Access. Every other vendor/product I'm aware of relies of separation of duties and doesn't try to roll user interfacing into what is rightly a back-end service.

    Administration tools for commercial and OSS databases may be easy for small sites and novice DBA's that don't know their tools, but large applications rely on database scripts to handle configuration, not GUIs. The reason is simple: you can't put a mouse click into CVS/RCS/SCCS/???.

    --
    I do not fail; I succeed at finding out what does not work.
  15. Re:SCO by 10Ghz · · Score: 3, Insightful

    Well, SCO also ships PostgreSQL with their product, can we trust the PostgreSQL-folks?

    --
    Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
  16. Re:Anyone know of a good free MySQL GUI? by pvera · · Score: 3, Informative

    Please mod up parent. Aqua Data Studio is a very damn good application, and the developer is extremely responsive. It is common to have him hang out in the support newsgroup for hours at a time, walking people thru things even if it is obvious they are too lazy/dumb/etc. to follow the documentation and FAQs. Between Aqua Data Studio (which btw runs on pretty much anything that can run Java) and phpMyAdmin, you should be able to do almost 99% of whatever it is that you need. The other 1%? RTFM and use the CLI.

    As for the SQL Server Enterprise Manager, it was a turd in 6.5, less of a turd in 7.0 and then got worse in 2000. The improvements added to Enterprise Manager for the jump from 7 to 20000 were pretty damn good, but they are offset by bullshit mickey mouse Jscript interface errors that have no place in a database management application. This sucks because the SQL Server Query Analyzer only got better and has none of these weird Jscript issues.

    For those of you stuck in the Oracle world (and cursing the Oracle provided tools), you may want to check out Benthic (http://www.benthicsoftware.com/), they have been publishing very nice and inexpensive shareware apps that work more or less like the SQL Server Enterprise Manager and the Query Analyzer.

    --
    Pedro
    ----
    The Insomniac Coder
  17. For good reason by Stone316 · · Score: 3, Interesting

    Most DBA's are adequate at best and most likely don't have much experience trying to squeeze every ounce of CPU out of a box. So I can understand why they do this... I personally don't take 'user' benchmarks very seriously because most times you have no idea how their environment is configured or if it is even configured properly.

    --
    "Thanks to the remote control I have the attention span of a gerbil."
  18. Read the fine print... by Decibel · · Score: 4, Interesting

    AFAIK the clustering and load balancing 'solution' for MySQL means your entire database has to fit in memory. Not very practical...

  19. Re:Having worked with oracle 10i for the last year by DrShasta · · Score: 3, Insightful

    You are talking about "massive" tables and a "reporting" application. Of course Oracle and DB/2 are the right choices for this. Has anyone ever thought differently?

    I've always used MySQL and it has always been extremely fast for me. But I've always known that it isn't meant for data analysis on massive amounts of data. The only time I've ever heard anyone compare MySQL to Oracle and say that MySQL was just as good as Oracle is when using small tables on a web app, which is exactly what MySQL is used for 99% of the time.

  20. Re:I see a problem by bwalling · · Score: 4, Insightful

    Hmm... I'm no database person but if you're creating a table that only allows a value of up to 127 and go over that, I would expect it to give you 127. What would a real database do?

    Return an error and don't make the insert.

  21. ODBC by abulafia · · Score: 4, Informative
    Now, my one pet-peeve in this area is that there is no linux equivalent of ODBC.

    There isn't?

    I just finished a project that accesses SQL Server from a Linux/Apache/mod_perl app using ODBC via the FreeTDS drivers. (Don't ask, client requirement.)

    Granted, not all of the unixodbc drivers are free. But then, they aren't in MS land either, although you might not notice because you're paying for them via a bundle.

    --
    I forget what 8 was for.
  22. Wow, very nicely done. by Some+Random+Username · · Score: 3, Informative

    You just posted what is quite possibly the single stupidest comment in the entire history of slashdot. Sorry, I don't think there is a trophy or anything, but you should still be very proud.

    First of all, its not graceful degredation, its data corruption. The entire purpose of constraints is to give you an error when you try to insert invalid data. Changing it to be valid data and not even telling you is completely and totally the wrong thing to do. How about if your data doesn't pass a constraint then mysql does a drop table, is that still good for you? Its just as helpful and makes just as much sense.

    Second, databases are supposed to have constraints, they store the data, they have all the rules of what is and is not valid data. Duplicating that in your code is absolutely brain dead, although its exactly what php/mysql developers have always had to do. This warps their minds and makes them think like you, that mysql is right, and everything else is wrong. Sorry, mysql is broken, every other database follows the SQL spec and returns an error when there is an error. Randomly changing data is not the correct response to an error condition, nor is there anything graceful about it.

  23. Ok, here goes... by krow · · Score: 3, Informative

    a MySQL developer say "yeah, I don't know what we were thinking, that's a really fucked up thing to do" Yep, its a fucked up thing. This is why we implemented strict mode for 5.0. In 4.1 you get warnings, in 5.0 if you are using a transaction table it tosses an error. If this is an issue, upgrade to 5.0. Personally for me it is.

    --
    You can't grep a dead tree.