MySQL 5.1 Released, Not Quite Up To Par 175
Mad Merlin writes "It's no secret that MySQL 5.1 has been a long time in the making, with the first beta release being in Nov 2005, but MySQL 5.1.30 has finally been released as GA. MySQL users can expect new features such as table/index partitioning, row based replication, a new plugin architecture, an event scheduler and a host of performance improvements from 5.1." Monty also had a blog post outlining some of the challenges faced in 5.1, including crashing bugs and a beta quality to most new features.
Wow (Score:5, Insightful)
Impressive, now MySQL can have features other databases (PostgreSQL among others) have had for *years*. I've never understood; people like MySQL because it is "light", "simple", "easy", blah, blah.... and yet they add all these enterprise features that then everyone will laud about how MySQL is "growing up" or some such. MySQL is one of the best examples of self redefined success I think I've ever seen.
If you want these features why not use a database that has had them for a long time, where they are better tested, and possibly get better performance under concurrent load as a side benefit.
news flash (Score:5, Insightful)
Just about every major non-open source project that has shipped with major bugs, the /. crowd jumps on for releasing poor quality products due to bad planning, poor communication, legal reasons, marketing deadlines, oh and the list goes on. When an open source project is shipped with major bugs though, what do I hear? Excuses. Is it just possible that people who develop open source are human, and make the same decisions, for the same reasons, as their closed-source counterparts? Which might lead to the conclusion that different methods don't necessarily yield different results; ie, that open source innately presents no inherent technical advantage over closed source, only social and legal advantages. Uh oh... they're getting a duck and a large scale out. I think that's my cue to post and run now...
Re:Beta Quality (Score:3, Insightful)
Re:well (Score:5, Insightful)
I'm not sure what you are trying to say. If we have to play car analogy - lets say both cars engines will fail if you go over 80 kmh on a sunday while wearing blue. One vendor will tell you before you buy the car - the other waits until you've been on the phone with roadside assistance for a couple days. The severity of the issue is the same - it's just how the manufacturer handles it that is different.
To step away from the metaphor for a second - I have had severity 1 service tickets open with Oracle support for over a day that ended up being unpublished bugs that were fixed with a patch that was not available until you knew you had run into the bug. Sev 1 to be clear is production systems down.
I worked on a project with an Oracle consultant who had been on his own before he joined Oracle. I asked why he made the switch and he told me it was for one main reason - so that he would get full access to all the documentation, including all the bugs and open issues.
Re:"Fair and balanced" summary?? (Score:5, Insightful)
Obviously 5.1 is not a perfect release. Quality is critically important to a database and I hope MySQL/Sun takes note of Montyâ(TM)s concerns, ...
However in my opinion MySQL 5.1 a very good release, long ready for general production usage.
You call THAT a rebuttal? My goodness... it no wonder MySQL sucks if he can admit on the one hand it's bugridden (not in those words, sure) and then say at the same time, it's ready for general production usage. What the hell does that mean?! It just makes me ANGRY to think people like this are DBAs! Does he mean to suggest your "general production usage" server is OK with lost rows and table corruption... if the chances of it happening are rare enough? Does he mean to suggest "general production usage" is a separate category from "people who use the advertised features of the product?" Seriously.... arrrrgh..... I think I'm having a stroke, I need to go take a valium or something.
Re:Wow (Score:3, Insightful)
In addition, since MySQL got so popular so quickly, developers were coming into jobs with experience in it but not in other databases. If you have five developers, each of which has used MySQL and nothing else, you're probably going to go with MySQL unless upper management puts their foot down, and in that instance they're almost certainly going to choose Oracle.
However, I see that changing more and more. The established programs and sticking with MySQL, but a lot of newer programs are using Postgres.
Re:well (Score:5, Insightful)
Well, you'd be a fool to buy MS SQL for its enterprise capabilities.
It has its strengths, of course, but it's most important strength is it is the default database slice of the Microsoft deployment stack and is well integrated with Microsoft development tools. For modest projects it provides the kinds of advantages MySQL does in the LAMP stack.
I'm not saying it is a bad product, depending on your needs. Nor am I saying that you can't do "enterprise applications" (whatever those are) if you design around its limitations. I'm just saying that if I weren't developing around a completely Microsoft based solution, I wouldn't give MS SQL a second glance. There are cheaper (open source) solutions on the low end, and more scalable solutions on the high end.
If maximum upward scalability from a PC host starting point was required, I'd go with Oracle. The fit on the low end is a bit awkward, but it's workable. You've got to be careful when you license Oracle because you can spend too much money very easily, but if you know what you're doing Oracle is scalable and cost-efficient. If you don't know what you're doing, that's a different affair altogether.
Re:news flash (Score:2, Insightful)
I think the difference is that a lot of open source projects operate on a release-early-release-often philosophy - what software engineers refer to as the waterfall model. In such a scenario, bugs will appear in earlier releases and decline in number sharply over time. Closed source projects tend to operate on the more classical release schedule, which tends to be a lot slower with a lot more expansive software lifecycle, but SHOULD produce far far fewer bugs in each release.
MySQL, with the current Oracle owners, seems to have moved to more of the classical mindset. That's fine and I personally don't think there's anything wrong with it if it's done right. But to be done right, you need fewer bugs in a release than the rapid-cycling of the RERO approach, and should aim for code of a quality comparable to RERO over the same timeframe.
It is clear in this case that MySQL has failed the test. It is a good product, but the new methodology is fixing less than the old methodology. That needs to be when the developers stop and think about whether they want to try switching to something else or go back to what had worked well in the past.
Re:news flash (Score:3, Insightful)
That's NOT the waterfall model.
Re:"Fair and balanced" summary?? (Score:4, Insightful)
What you responded to was an out of context quote, which by omission seemed to combine two sentences. In context my words might be less valium-inducing to you.
"""
Obviously 5.1 is not a perfect release. Quality is critically important to a database and I hope MySQL/Sun takes note of Montyâ(TM)s concerns, especially about core developers working on fun new projects like Drizzle and leaving relatively inexperienced developers fixing bugs in their core business product.
However in my opinion MySQL 5.1 a very good release, long ready for general production usage. Definitely test it before you use it, like you should also test new kernels, Apache versions, distribution releases, etc. But do not alow this sensationalist blog post to overshadow what should be considered a solid engineering accomplishment by the MySQL team.
"""
Re:Wow (Score:2, Insightful)
MySQL is very easy to use and configure the first time. Postgres isn't nearly as simple.
On what do you base this statement? Having used both, I do not agree and think they are about the same. Would be nice to hear what other find hard with Postgres set up.
However, I see that changing more and more. The established programs and sticking with MySQL, but a lot of newer programs are using Postgres.
I would prefer if the programs were written so that you could use the RDBMS you already have installed. For me this is a small hint that the developers might have a thought when it comes to design.
Re:5.0? that so? (Score:4, Insightful)
Re:Wow (Score:3, Insightful)
On what do you base this statement?
Experience. I've used MySQL for years and didn't have any problems with configuration. It worked out of the box for everything I needed. Just last night I was configuring Postgres and had some issues with the configuration that I had to look up in their manual. The same thing in MySQL would have taken me thirty seconds now, and no more than 15 minutes when I was starting out. With Postgres, it took me upwards of 20 minutes when it should have taken much less time. MySQL is more willing to hold new users hands and has a lot of easy shortcuts built into it. Postgres does things well and gives you a lot of options, but it's not as forgiving to new users. Things like "SHOW TABLES" are either considerably more difficult in Postgres or harder to find out.
I would prefer if the programs were written so that you could use the RDBMS you already have installed. For me this is a small hint that the developers might have a thought when it comes to design.
When you're using MySQL for applications that aren't being distributed and installed by your customers, but are running on servers you control, there's no real need to make it work with any database other than the one that you're using.
Re:Wow (Score:2, Insightful)
If they've used MySQL and nothing else, they're probably self taught and don't really understand what they're doing.
Re:"Fair and balanced" summary?? (Score:2, Insightful)
Heh (Score:3, Insightful)
Depends on what you call "par", but for my values of "par", MySQL has never been there.
Re:Wow (Score:2, Insightful)
I think you proved his point... to an inexperienced user what you just posted is gibberish where "show tables" is plain english and something you might type as a guess.
To someone very familiar with reading option syntax sure that makes sense... but that is a much smaller group. Just figuring out that \d{t|i|s|v|S} means /dt or /di or /ds etc assumes a certain level of knowledge.
Re:5.0? that so? (Score:5, Insightful)
If you allow your users direct access to SQL and rely on SQL permissions you probably shouldn't. Most MySQL setups have no way of allowing untrusted users to run SQL directly so they can't run a drop table statement. So yes, if your letting complete strangers run SQL on your database you might want to look somewhere else.
Re:"Fair and balanced" summary?? (Score:2, Insightful)
>they outsource SQA process
I gathered that, just from the username.
I must say, I'm heartened lately, since several clients have become willing to admit that their outsourcing-to-India adventures have worked out to be net liabilities. I mark this as the end of a trent that I saw coming, warned about, experienced the first (and last) time I managed an offshore team, and I have a special little "I told you so" dance for the situation.
Yeah, I know, you're reading this in Bangalore and I'm an insensitive clod.
Re:The first time I used MySQL... (Score:3, Insightful)
You are both essentially in agreement, and what you're saying boils down to "I'm used to X, and when I tried to do the same thing with Y, which I'm not used to, it took me longer that it would have done with X". It doesn't really say anything about either MySQL or Postgres.
I've used both systems a fair bit. As a sysadmin I find MySQL easier to work with, because the way the data files closely mirror the structure of the database, and it doesn't mind too much if you tar up a database, copy it over to another machine, and start it up. Postgres's on-disk format is by comparison pretty obtuse, and if you get data corruption it's a lot harder to recover from. (Of course if you're doing it properly you've got battery-backed RAID and periodic hot backups to restore from, but this isn't always within budget or the data isn't that important).
When I've got my developer hat on I prefer Postgres because it's more strict and more predictable and feels a lot more refined.
Preferences come down to what you're used to.
Re:"Fair and balanced" summary?? (Score:2, Insightful)
Wait a minute... outsourcing is now a valid reason for poor quality?
That and the _massive_ cost savings should make anyone who suggests it a candidate for CEO!
too much adoration of personal database favorites (Score:3, Insightful)
While I'm currently a CIO for a small-to-mid-sized company, I've been using relational databases now for more than twenty years.
For years, I've been HEARING about crash issues using MySQL for transactions. For as many years, I've been designing databases and supervising application design that use MySQL for small transaction systems without corruption problems at all. During this time, I've also designed many large read-only tables used by query systems with millions of records without corruption problems.
For more than a decade, I experienced crash after crash when using SQL/Server for databases above a few million records and/or above a couple of hundred gig. Over time, the product got better. Today, my group uses SQL/Server for production applications with almost a hundred million records updated daily with no corruption reported in YEARS.
I've been using Oracle since the 1980's on many platforms. Yes, the early days (pre version 7) were grief and suffering when building OLAP applications. However, each version since Version 7 (1995? 1996?) has been better than every alternative that my employers would consider (including IBM's DB2,) and I am still very comfortable betting my job on Oracle when data warehousing is involved.
When faced with new challenges, I'm free to select any database application so long as I know my job is on the line when something fails. As a result, mission critical applications will still be coded in Oracle and non-critical applications that we can take our time stress testing are mostly done in MySQL.
I still have to use SQL/Server as commercial tools our accountants use (MS Dynamics and Clarity) will work on nothing else.
Instead of cursing every product with which a writer has had bad experiences, the key to reducing grief is to remain aware of the likely risks and rewards of each approach. Yes, Oracle is expensive, but the risks to one's company and personal employment often make it the right choice. Yes, using tools that cost the most will sometimes put a business at a pricing disadvantage and that is when looking at MySQL is sometimes a key to success.
What I could really use is a grid that compares current versions of each product and recommends the likely characteristics of appropriate applications. (For all I know, my own preferences and rules may already be out of date.)
Re:Wow (Score:1, Insightful)
Inexperienced users use client/server databases?
Inexperienced users might use Access, maybe. But Postgres or MySQL? Seems like someone shooting to move up that rung up the ladder would likely start with a tutorial, I know I did.
Re:too much adoration of personal database favorit (Score:4, Insightful)
Instead of cursing every product with which a writer has had bad experiences, the key to reducing grief is to remain aware of the likely risks and rewards of each approach.
We can be as relativistic as we want, as though every system is a snowflake with it's own beauty, but in the real world, sometimes value judgments are useful.
For instance, if you design a truck and I design a car, we can both respect each others' designs, and differ on opinion. You might prefer towing capacity, and market that benefit to construction workers and farmers. I might market the fuel economy and handling to commuters.
If someone designs a car that sometimes explodes when it rains and the steering wheel in the trunk, it's a bad design, period.
Re:Wow (Score:3, Insightful)
So now MySQL had two forms of replication, and Postgres still has... Log shipping. Call me a noob, but I'll take MySQL any day.
Postgres has had Slony for replication, and has done so for years. As for MySQL, I haven't touched it since version 4.1, and while it may have come with replication in the same tarball as the DB engine (whereas Slony is a separate package) it proved very unreliable. The worst thing about MySQL replication was that when it crapped out, it would not issue any warnings and provided no mechanism for notifying us of problems.
The bottom line is that it is embarrassing (Score:3, Insightful)
"Even if we have fixed a big majority of the bugs from 5.0 some really critical ones still haven't been addressed."
That's the sort of attitude more than a few people still expect from this "open source stuff".
The pivotal thing about MySQL is that they released a Windows version early and it got on CDs bundled with a ton of programming books. In my opinion, that's why we are talking LAMP instead of LAPP.