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."
And of course you can't include Oracle in any impartial study.
Hmm... do I smell... fear?
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Does 5.0 have all the issues with data integrity sorted out? These are VERY important to me.
Working "ROLLBACK" even with millions of rows.
No silent data truncation.
No silent "BEGIN TRANSACTION" on unsupported table types.
No being able to drop a table if it is referenced in a foreign key.
etc etc.
Once these are fixed, I will look at how well it performs compared to real DBMSs.
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
They are only subject to harsh criticism due to their attitute (which may have changed since).
They used to simply shrug off features like transactions and views saying things like "you don't need them", and "you can code around them in your app".
To date, mysql (4.1) does not maintain data integrity anywhere near as completely as real DBMSs do.
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.
The license you describe doesn't say anything about server usage.
Clearly, the main-use for MySQL lies in server-client architecture. As long as you do not ship your self-created web-application, I see no reason you should be suspicious about MySQL.
Write a specification document. Seriously. I haven't used Access since I was at school, and I honestly have no idea what it does that is any use. I suspect a lot of the people who are capable and willing to program an Access-replacement are in a similar position. Tell the community what you need. Just saying `nothing exists that fits my undisclosed requirements' does not help anyone. Please send me the URL once you have put the requirements online.
I am TheRaven on Soylent News
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.
The key paragraph here is this one:
* 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.
So, unless you actually distribute/modify/copy MySQL, then you are free to do whatever you want with the database.
This is actually why some of the newer Linux distros don't include a version of MySQL with the OS...it's offered as a seperate RPM/DEB/PKG/etc...
Nothing has changed...this doesn't mean that you can't write an app that uses MySQL and release it under a LGPL/BSD/Proprietary license...as long as you aren't modifying the code in MySQL, then you're fine.
Postgres may have a few things going for it over MySQL, but license is not really one of em...
Your argument has a weak point - there's no reason why you couldn't instead embed a BSD licensed DBMS in a GPL application. It wasn't going GPL that 'empowered' these developers. BSD licensing has no restrictions other than a credit line.
I'm not saying the rest of your points aren't valid - but saying that MySQL is where it is today because it was GPL just doesn't fit. I think it's where it is today because it started out dead simple, and people latched onto that - just like PHP.
cyn, free software and *nix operating systems enthusiast.
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.
PHPMyAdmin and MySQL Control Center are database management GUIs. I don't think they're supposed to be Access-like apps, and I'm personally happy about that, since when doing DB admin I don't want a tool that tries to second guess me, hides things from me, etc.
One Access-like app is OpenOffice.org 2.0 Base (Go test it and report issues before the final OpenOffice.org 2.0 release!). It's extremely new and it's rough around the edges, but it looks decent. It's an Access clone to the point where I'm surprised Microsoft aren't suing about stolen icons.
If you're looking for something in the same vein, but not seeking a direct Access rip-off, then Rekall may be an option worth investigating. Both it an OO.o are cross-platform.
Do be aware that tools like Access encourage you to do too much client-side. It's important to consider using in-database stored procedures and (often updateable) views where appropriate for efficiency and clean structure. You can then use an Access-like app to provide a user-interface to that higher level database interface, instead of just poking around in the raw tables.
You obviously missed my point, so I'll try and be a little clearer.
The problem is not that they wrote software with bugs. And obviously I'm not complaining about fixes, as you seem to be implying.
The problem is the nature of the bugs that they introduced. No developer who is competent to work on a database would ever, in a million years, think that silently altering and discarding data without the application's knowledge is an acceptable thing for a database to do.
So basically, if we know for a fact that they were incompetent before, and they've showed no signs of understanding just how incompetent they were, why would we believe that they are competent now? And if we don't take it on faith that they've magically become competent without anybody noticing, then why would we trust a database that is developed and maintained by incompetent developers?
Clearly, it is a real database that is capable of doing real work.
I disagree. A real database wouldn't allow this:
CREATE TABLE t(t tinyint);
INSERT INTO t VALUES(300);
SELECT * FROM t;
You really meant 127 and not 300, right?
I looked up "graceful degradation" and it didn't have anything at all to do with the subject at hand. Allowing malformed or errnoenous data to be inserted into a table which has been expressly defined to disallow data in that size, shape or form is totally broken behavior. For a database to accept such data is neither graceful nor is it degredation.
/something/ into the tank, even if it's the wrong fuel?
I suppose you'd also argue that it's a bad idea for the Diesel and Petrol gas pump nozzles to be different sizes, because it should be possible to accidently pump diesel into your petrol-burning car. After all, isn't it better to get
No, rather, I'd expect you might consider the different sized nozzles to be a wise safeguard against the unavoidable human errors which would otherwise occur. Similarly, being able to enforce data integrity at the most logical layer -- the database -- is also a wise and necessary component of any database system which expects to be taken seriously.
TSearch2 is a full text search module for PostgreSQL that has been available for a long time. It's stable and not in beta.
What's wrong with modules? They're great. It means that you can upgrade TSearch2 or some other module without waiting for the next release of PostgreSQL. It's not difficult at all to install the modules, just copy some files and run a SQL file.
I think that PostgreSQL making use of it's extensibility by forcing some functionality out into modules was very successful from a technological standpoint, a release process standpoint, and a user's standpoint. However, it certainly was a marketing failure. Now everyone thinks PostgreSQL is missing those features. PostgreSQL has never been known for it's marketing abilities.
Social scientists are inspired by theories; scientists are humbled by facts.
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.
> 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?
Yes - everytime a product or technology is overhyped people believe it will do everything. Search for mysql and data warehouse - you'll find plenty of people who think it can handle massive data without really understanding what db2/oracle/informix/etc do that's different.
> 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.
Right - in that context mysql/postgresql are competitive. Of Course, that isn't what MySQL AB is telling people. Little surprise, these are the same people that a few years ago were telling people that they didn't need primary key/foreign key constraints either.
Anyhow, I've got an application right now that for its first two years stayed quite small - just a few thousand rows. Implemented in db2 - since we need a major database anyway for the larger databases with a billion rows, and we can save labor by staying consistent. Anyway, this little database is about to now explode in size due to expanded requirements and new customers - we're expecting one little critical table to go from 3,000 rows to around 500,000. Its history table will go from maybe 10,000 to 10,000,000 rows. Other tables throughout the databae will likewise expand. DB2 was overkill when this database was first created, now it's perfect: it'll support the heavy transactional loads, automated system failover, and very fast scans, reports and other tough queries. This application growth is not at all uncommon - everyone is putting far more data into databases than they were just a few years ago.
So yeah, mysql and postgresql are neat products, but their lack of scalability for massive tables or analytical queries is a major gap. And the requirements for this capability are now commonplace - unlike ten years ago when only a few data warehouses really need it.
This isn't the case with PostgreSQL or MySQL. You never get that "drug pusher" type of attitude.
Are you kidding? MySQL is TOTALLY a "get our hooks in drug pusher" kind of company. They're the "Project Mayo" of the DB world. Their development/business model revolves around getting everyone onboard with the open source version and then exploiting the open source development community with their policy that copyright to patches and improvements must be transfered to MySQL so they can then be sold closed-source.
And on top of all that, their product sucks. Good enough for internal content management or a free forum perhaps, but hardly something you'd trust with important data. They obviously agree, or they would have stuck to developing their existing codebase rather than using SAPs.
Why do people spend so much time cheerleading for these guys?
-1 Uncomfortable Truth
The MySQL developers have been subjected to some very harsh criticism over the years, but few would accuse them of ignoring it.
Then why did they dismiss all the criticism in the MySQL 3 manual, even claiming the features make databases more complex and aren't needed? Some of those features are now in MySQL 4.1 and 5 despite their earlier dismissal by MySQL's developers.
"Sufferin' succotash."
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.
No it doesn't. The FLOSS License Exemption means that your application is not forced to be GPL if it uses any of 20 of the most popular free software licenses. The exempt licenses include the LGPL, the MIT and BSD licenses, the Mozilla license, the licenses for Perl, PHP, and Python... and the list goes on. In other words, the vast majority of free or open source software is able to link to the MySQL client library without being forced to change its license to the GPL.
This is a significant relaxation of the regular GPL terms. It even makes explicit allowances for users of the BSD license, the group that traditionally dislikes GPL software the most.
The only people who can complain about the MySQL licensing policy are freeloaders who want to benefit from free software without giving anything back to the developers or the community. You will, I trust, forgive me if I don't weep for such people.
I strongly suspect the slashdot editors have a bet as to how many times they can post a MySQL story and have the same debate, with more or less the same bashing, arguments, and counter-arguments repeated all over again.
It's must be their secret revenge on the fraction of the readership screaming DUPE! every time they post a story resembling an earlier story. Now, they can read their latest MySQL story, point at almost any comment, and scream "DUPE!" they too!
Of course you can embed a BSD-licensed DB into a GPL project - the BSD license permits that, along with everything else.
The point is this: Postgres has existed much longer than MySQL. Yet as the OSS, and particularly GPL, movement caught on, and a large number of OSS apps were produced, MySQL managed to be included in many of them, and Postgres and Firebird did not. I don't really think all that many people sat down and evaluated Postgres vs. MySQL - they just learned about MySQL, heard that it was GPL (a Good Thing), and built their GPL app on it. Had Postgres been easier to set up in those days, would people have used it? I don't know, and nobody can, but I'd guess that MySQL being GPL helped propel it to prominence when Linux was really taking off, and the rest of its success is largely network effects. Given how many shortcomings it had and has, why else would people have preferred it over a more feature-complete BSD-licensed database?