Slashdot Mirror
Major Changes To MySQL Coming Soon
Meltr writes: "This ZDNET article details some of the coming changes to the MySQL database server. In 4.0, to be released in mid-October: 'support for the Unicode character set, the SSL (Secure Sockets Layer) protocol, embedded database links and multitable updates' and in 4.1, to be released in December: 'nested queries and stored procedures'."
Hmm I guess this means its a good thing that I didn't buy the MySQL book because its all going to change. I hope that the differnces aren't very complicated to interchange between so that the people who are familar with MySQL now aren't going crazy tring to retrain their brain for the new versions. But its only a hope.
Excellent. One of the reasons my company decided to hold off on porting to mysql was the lack of stored procedures. A pity; now they've moved to DB2 and the moment is lost.
"Einstein argued that [...] God is not capricious or arbitrary. No such faith comforts the software engineer." ~ Brooks
What I'd like to see is a profound comparison of mysql and postgresql. I'm a happy user of both, and I currently have pgsql serving a 8 million pageviews/month site, and handling load gracefully. AFAICare, pgsql is at least fast enough. I also never had any reliability/data loss problems with mysql, despite heavy concurrent access. AFAICare, mysql is robust enough. I'd really like to find out what are the core differences in both designs to get a grasp of how fast they may evolve.
If at first you don't succeed, skydiving is not for you
1. Microsoft Access is more functional, easier to use and deploy than MySQL.
More functional? I could explain theoretically why that statement is utterly ludicrous, but I'll merley give a practical example:
A big British financial organisation maintained internally, its publicly available financial data in Access. I wrote a system for them, using GNU/Linux, MySQL and mod_perl, which allowed web visitors do perform complex searches on this data. The internally-maintained big Access dataset was imported into the MySQL datbase via an import system I wrote for them. Now here's the interesting thing - they began to realise that the web-based system, even over an ISDN line, returned data substantially more quickly and reliably than did Access, even after they upgraded to the (ACID compliant) SQL server! Indeed, the latter constantly corrupted their data, would get into all sorts of unremovable row-locks and god knows what else in its attempt to remain beautifully ACIDic. Eventually, they ditched it and now use my system (with a content management client they've had written which accesses MySQL via myODBC). They've been using this for just under three years now, and there has not been, cumulatively, even one minute's downtime.
You're missing the point. The start of this thread was puzzlement over why, exactly, mysql is so popular in this community when more complete and more robust alternatives exist (like postgresql).
There is no strong motivation to bring mysql's featureset up to the accepted standards for a sql server when we can all just run postgresql and have those features now, in a more mature and well-tested form.
I'm constantly puzzled by the enthusiasm and support shown for mysql and simultaneous aversion to postgresql because both attitudes are clearly not based on technical merit. And, to make matters even more confounding, mysql's popular support and user community rallied behind it long before it was actually capital-F "Free" in the religious sense. So, we can't even settle on mysql's popularity being dogmatic which would be an understandable reason.
I haven't seen anyone in this thread complain that mysql lacks features. I'm just seeing people wondering why we should be motivated to use a deficient product when better alternatives exist.
According to the article:
"The GPL allows open-source programs to be changed by users, but those changes aren't official and can't be sold commercially unless they're given back to and accepted by the owner."
That's not exactly how I understood it. My impression was that the GPL was a recursive license allowing the free use and modification of code, but requiring that said modifications also be made freely available under the GPL. I didn't think the person whose code I was modifying had to accept my modifications in any way. Nor did I think it was directly incumbent upon me to send them to him.
I wonder what it is about journalists that makes them so capable of half-understanding so many things?
My company is currently trying to decide between MySQL and PostgreSQL, with the latter being the likely choose.
We're currently using Interbase, and I have to say that it's the biggest pile of fetid horror I've ever had the displeasure of having to maintain. Why?
The only reason that we're using the much-despised database server is that our rather largish apps are written against it, and it will take a bit of effort to change. Also, given the lack of the SQL dump utility (other than the hack job I put together), getting information from Interbase to anything else is non-trivial.
It may be good in theory, and I'm sure that some people like it. For us, however, Interbase is completely undependable and just barely usable for routine tasks.
Dewey, what part of this looks like authorities should be involved?
I have used MySQL for web-based applications only until now. And while I like it because it is fast, easy to install and administer, as others have alread pointed out, I find it still lacks some rather important "features" (like views, nested queries and stored procedures), a fact that makes MySQL a non-choice for most of my customers at the moment.
Hi! I agree that PostgreSQL has some fetatures that MySQL also has, but it's also true that MySQL has a lot of features that PostgreSQL doesn't have.
To not have to repeat myself over and over again, I have collected some information about this topic here
Speedwise I haven't seen any indication that PostgreSQL 7.1 would generally be faster than MySQL. All the tests I have myself run shows that it there is no big speed improvment between earlier PostgreSQL version and 7.1, if you run both with flushing of data disabled. (We will soon publish the results on our benchmark page)
For many applications, MySQL is in practice at least 3 times faster than PostgreSQL 7.1. If you applications needs the extra speed MySQL can give, PostgreSQL is not an option.
According to what I know, the InnoDB transaction handling engine in MySQL is at least as good as the PostgreSQL transaction engine. (I would argue that is even better, as you never have to run a 'vacuum' on InnoDB!)
My simple message is that both MySQL and PostgreSQL has a place. One can't generally say which is better, in the same way you can't say if a hammer or a screw driver is the right tool, if you don't know what it should be used for. For a lot of real world applications, MySQL is simple the best choice. The same is true for PostgreSQL.
Regards, Monty
CTO of MySQL AB
Wearing my programming hat, I have to use the right tool for the job. If I don't need lots of nifty DB features, I'll use my native filesystem structure to store data, or even a flat file. Remember those? If I need bells & whistles, I'll choose a DB that has just what I need, and no more. Why waste cycles (or licensing fees) on worthless features? If I need transactions (for example), and I don't want to spend $$ on proprietary DB licenses or on man-hours trying to figure out a complicated open-source DB (remember TCO?), I'll code it myself with something simple like MySQL on the back end. If I do need scalability/lots more features/whatever, I'll pony up the time/money for the big boys.
Right tool, right job.
This post expresses my opinion, not that of my employer. And yes, IAAL.
I used MS SQL v6.5 years back and I can tell you that compared to MySQL it is very slow and most importantly, extremely unreliable. MS SQL cannot handle the load that MySQL can. At my previous company (care2.com) we had a dual xenon (PII 350MHz?) machine performing an average of up to 600 queries per second during peak hours. Sure I miss stored procedures, but running stored procedures on a database doing hundreds of queries per second is not realistic. It makes more sense to have clients do as much of the work as possible to reduce the load on the centralized DB. I guess if you have a minimal DB load or a mainframe you could successfully argue this point.
Deuteronomy 13:06-9