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."
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
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.
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?
> 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.
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.
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.
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.
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.
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.
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.