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.
"Fair and balanced" summary?? (Score:3, Interesting)
Ryan Thiessen, a long-time 5.1 user, strongly rebuts Monty on his blog. [hideandsql.com]
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:"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: (Score:2)
Your blog post didn't make up a rebuttal so much as they put things in perspective. A perspective I do not share, but a valid perspective.
I agree with Monty on this one. Advertising features with major known problems is irresponsible, and it's just asking for users to get into trouble.
And still having so many of these problems after a 3-year release cycle doesn't look good.
Re:"Fair and balanced" summary?? (Score:4, Funny)
...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.
I think that just brings it up to the major leagues. I mean Oracle managed to ship production versions of its DB with developer's home directory hardcoded into startup script [oracle.com] which without modifications would not allow you to start DB. How does something like THAT pass QA?
-Em
Re:"Fair and balanced" summary?? (Score:5, Funny)
>How does something like THAT pass QA?
That's REALLY unfair to blame Oracle for QA processes... they outsource SQA process, so it's a SUPPLIER problem.
Re: (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 clo
Re: (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!
Re: (Score:2)
What the hell? You have to re-attach databases? I've been using SQL 2005 since 2005 and have never run into that in clustered, mirrored, replicated, or even Oracle published environments.
The only hiccups ever encountered are around restores of backups to different servers which can sometimes be tricky if there are connections that refuse to close on the destination DB.
If you're having to re-attach it sounds like there is something wrong with the install or maybe I've been exceptionally lucky. I would clas
Re:"Fair and balanced" summary?? (Score:5, Interesting)
It sounds like MySQL could benefit from a more debian-like release criteria [debian.org].
5.0? that so? (Score:3, Informative)
I've been using 5.0 in production for well over a year and found no 'critical' bugs. (For most of that time I had access to MySQL's paid support.)
As Ryan said there is no such thing as bug free software but there is such a thing as production-ready software. MYSQL 5.0 HAZ IT.
Re:5.0? that so? (Score:4, Insightful)
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: (Score:2)
Re: (Score:2)
Sadly at the current state this is kinda like old windows NT permission. More of a suggestion to your already trusted user set. If your putting this out for untrusted users to access directly you need something more secure. MySQL is production ready but in only certain ways.
Re: (Score:2)
what about hosted environments ?
Re: (Score:2)
As Ryan said there is no such thing as bug free software...
Some of the bugs in Monty's list are pretty scary.
Your standards for a DBMS are different than mine.
Re: (Score:2, Insightful)
RTFB. (Score:2)
-> 18 months.
well (Score:3, Interesting)
maybe they are just trying hard to be more like the commercial enterprise databases. my experience with oracle was that they have a lot more bugs than this - it's just you can't actually find out about them until you call support. Then you find out they have known about it for some time, they just don't publish it. They hide all this stuff instead and only let certain things out.
Re: (Score:2)
that was tongue in cheek - the truth is with that list MySQL is still doing better than what one will get with a lot of commercial dbs. MySQL still lags in features (all the FOSS rdbms solution do) but it is catching up fast. When partitioning and master/master replication fully arrive it will be an incredible option. Those are expensive features anywhere else.
I remember being at the MS SQL Server 2005 launch and the presenter had to mention that one of their new replication options would be "inc
Re: (Score:2)
When partitioning and master/master replication fully arrive it will be an incredible option.
By arrive do you mean "GA" or "actually works"?
Re: (Score:2)
Actually works - that was kind of the point of the MS SQL Server illustration. It's pointless to ship something that is broken - but for some reason it happens with open and closed projects.
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: (Score:2)
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.
On the low- to middle-end, you could try PostgreSQL's Oracle-compatibility layer.
Re: (Score:2)
If maximum upward scalability from a PC host starting point was required, I'd go with Oracle.
i don't remember where did i read this, so sorry about not attributing the citation.
"Oracle does not scale well.
Financially."
best spoken out, with long enough pause.
Re: (Score:2)
Not saying either product is better than the other but you're acting like a guy selling you a BMW 325i with a burtn out headlight is selling you the same thing as the other guy who is trying to sell you a 1982 Yugo Cabrio with a blown engine
It depends. What kind of blower does the Yugo have? Turbo or supercharger? Is a hole cut out hood to accommodate? The Yugo might be pretty sweet!
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: (Score:2, Funny)
If your car dies, just do what microsoft suggests, and close all of the windows. maybe the car will then restart?
Re:well (Score:5, Informative)
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'll second this. We just ran into such a bug when trying to restore a database.
The application connecting to the database was upgraded, and something went wrong when it tried to modify the schema, so we rolled back to the backup taken immediately before the start of this. Normally, this would have been simple, but apparently there's a bug with our version of Oracle that caused the restore to fail. Luckily, it only took an extra couple of hours to work around and we were still in our planned outage window, but it still sucked that it was a bug known to Oracle.
Of course, we didn't hit the Oracle bug in our development and test systems, because the application didn't fail in the schema update on those, thank's to Mr. Murphy.
Beta Quality (Score:2)
beta quality to most new features
Beta quality is meaningless term now with Google in permanent "Beta" mode for many of its stuff.
If it is "Google Beta Quality" (tm) then who cares????
Re: (Score:3, Insightful)
Re: (Score:2)
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.
Re: (Score:2)
I love PostgreSQL - it's my personal favorite. But that doesn't stop me from realistically looking at features. I'd love to see them implement real partitioning but it's not there yet. Last I checked master/master replication was still not really there for PostgreSQL either. If these features came to MySQL first would you change your tune?
Then there is just the reality of the fact that MySQL did gain a huge amount of momentum and there are lost of people out there (myself included) who have to w
Re:Wow (Score:5, Interesting)
I think his argument is more marketing/PR driven. His main point is valid, in that MySQL claims simplicity/lightness when they don't have the features, and claims maturity when they add them.
Re: (Score:3, Informative)
... master/master replication is buggy and will frequently just stop replicating in one direction or the other. It's easy enough to fix (once you've learned how...the documentation could be a lot more thorough), but it's annoying that we have to do it so frequently.
You can also file bugs against the docs (Category is "MySQL Server:Documentation"). Please do so.
It would help resolve the issue more quickly if you could supply at least some of the information that you think is missing.
Thanks for helping other MySQL users!
Re: (Score:3, Insightful)
In addition, since MySQL got so popular so quickly, develope
Re: (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: (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 han
Re:Wow (Score:4, Informative)
.... Things like "SHOW TABLES" are either considerably more difficult in Postgres or harder to find out. ....
More difficult? Harder to find out? Consult help by typing \? and you will see this:
[snip]
Informational
\d [NAME] describe table, index, sequence, or view
\d{t|i|s|v|S} [PATTERN] (add "+" for more detail)
list tables/indexes/sequences/views/system tables
[snip]
Then type \dt to show the tables. To me that does not present it seld as more difficult or hard to find out.
Re: (Score:3, Informative)
Re: (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.
The first time I used MySQL... (Score:5, Interesting)
I've used MySQL for years...
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.
That's because you know MySQL, so of course something that works differently is going to be more work for you to figure out.
I've used PostgreSQL for years, when I had to set up a MySQL database for some php app it took much more than 15 minutes to figure it out and get it running. The primary problem was MySQL's obtuse user management system.
With PostgreSQL I know that it's secure by default -- the default user has no password, so even if you enable password authentication it won't work (because it has no password!). You log in locally with trusted authentication, and issue the very logical CREATE USER. Edit the self-documented config file to allow remote hosts to access the database using your preferred authenticaion method, and you're done.
With MySQL, new users are automagically created by the GRANT command?! Huh? On top of that, passwords are apparently specific to a certain host string. Bizarre. Do I need to use localhost for the actual machine name for local users? What about remote machine without a reverse DNS entry? What's the order of precedence for '%' vs a more specific name?
Oh, the default 'root' account has no password ...and allows access over the network. Wonderful. Okay, so to change that do I use root@% or root@computer? How do I know I changed the right one and there isn't still some root@something entry? SHOW TABLES is easy enough, how about SHOW USERS? Nope, that's not it.
Time to check the startup guides. Well, one just has a single password change, another has 3 or 4 lines of 'delete from user...'. The reference for GRANT just has a bunch of caveats and warnings, and the "User Account Management" section goes on and on and somehow doesn't manage to tell me what I want to know.
To this day I'm not 100% sure if the MySQL install is secure. I decided my time would be better spent eliminating the MySQL-isms from the app in question so that it can run on Postgres like everything else on the server. There are some very strange queries in there - a lot of GROUP BY expressions that make no sense and aren't valid SQL. Some of it I'm not sure how it ever worked.
Re: (Score:2)
That's because you know MySQL, so of course something that works differently is going to be more work for you to figure out.
I spent much of last night doing my third Postgres install. It took me roughly one and a half hours to get it to where I wanted it, with a user that can access it over the local network and an empty database from which to build my app. My third mysql install took roughly 20 minutes to get to that point, and that was a few years ago when I didn't know half as much about databases as I do today.
I don't know what the general trends in the population are, but for me and the people that I've dealt with, MySQ
Re: (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
Re: (Score:3, Informative)
The manual seems to describe this in the connection access [mysql.com] and request access [mysql.com] sections. It answers your question on precedence (most specific to least specific, first match wins), but not the others. You
Re: (Score:2)
With Postgres, it took me upwards of 20 minutes when it should have taken much less time.
If you mention the issue, who knows? Maybe it will be fixed.
Usability or documentation issues are not always obvious to the developers...
Re: (Score:2)
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.
That's a good goal when designing a system that has to integrate into and with 3rd-party systems. I.E. an app designed to be sold to 3rd parties.
However, doing so for an in-house app is stupid, as you won't be able to take advantage of any of the features of any particular RDBMS. In that instance, I think it's better to simply isolate the RDBMS-specific bits rather than leaving them out altogether.
Re:Wow (Score:5, Informative)
MySQL is very easy to use and configure the first time. Postgres isn't nearly as simple
I've heard this a few times. I've installed PostgreSQL on Windows, Linux, FreeBSD and OpenBSD. Every time, the process has been:
How does MySQL simplify this?
Re: (Score:2)
To be honest, and I'm a total pgsql fan, you usually wind up needing to edit pg_hba.conf and reload to allow external access. But yeah, it is about as easy to me as mysql.
Now, 6.5 was a bit more of an exercise to install.
Re: (Score:2)
To be honest, and I'm a total pgsql fan, you usually wind up needing to edit pg_hba.conf and reload to allow external access. But yeah, it is about as easy to me as mysql.
Although, the primary deployment for MySQL seems to be running on the same machine as the web server. In a direct comparison of that case, you don't even need to change pg_hba.conf.
The default config isn't secure if you have untrusted users on the machine (i.e. hosting service), unless you used "initdb -A md5" or something similar, but it's easy to change.
My favorite auth method for server-in-a-box is "ident sameuser" over UNIX sockets. In that case it seamlessly integrates with the OS's underlying securi
Re: (Score:2)
It just does things differently, the storage space is configured in files and databases are created with SQL queries. Essentially, after you install the MySQL package, you can just run the `mysql` client and create databases and users as you wish. I see that compared to this, pgsql requires some additional setup before getting at the SQL prompt.
Re: (Score:2)
Re: (Score:2)
Pretty buttons that say next >>.
Re: (Score:2)
How does MySQL simplify this?
3a. Install phpMyAdmin ;)
Re: (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: (Score:2)
MySQL is very easy to use and configure the first time.
I've installed and used postgres, MySQL, Oracle and SQLServer. Oracle and MySQL were the worst. Oracle because it was just horrible to install, MySQL just because it was hard to install in a configuration with even a hint of ACID compliance at the time. It was that experience trying to configure MySQL for data integrity that caused me to dump it and move to Postgresql.
The fact is, a DBA or programmer that only knows one DB engine knows nothing about his
Re: (Score:2)
Re: (Score:3, Informative)
One thing I like about postgresql vs MS Sql is the triggers. MS SQL triggers are after-insert, per statement only, IIRC. Pg triggers are per statement or per row, before or after. There's also a rule system and the ability to rewrite the query, for updateable views or other tricks. The lacking features are clustered indexes, replication, and partitioning. I'll also mention hash indexes -- it has them, but they're not journaled, and they're not generally recommended. I'm not going to comment on MySQL s
Re: (Score:2)
Sure, other databases are nice (Score:2)
PgSQL is not the only, nor necessarily the best open source choice. There are DB2, Firebird, Ingres, and dozens more. Some of them have mature implementations of the features new to 5.1.
MySQL is a very valid choice also, for a variety of reasons that you may not have considered. Or are you saying Facebook, Flickr, Yahoo!, Google, Slashdot, SABRE, Wikipedia, YouTube are all stupid?
The world just isn't as simple as you think.
Re: (Score:2)
DB2 isn't open source. They do have a limited free-to-use version (like Oracle and SQL Server), although DB2 has no connection or storage limits.
Re: (Score:2)
There are ups and downs to any project. When I had a Postgres database to admin, I was told to look into replication. After a frustrating few days of determining that there was no 'replication' (unsupported patches and log shipping don't count), I was then chastised by the postgres-loving lead revel because 'we don't need replication' because the app isn't going to split reads/writes and that's all replication is good for.
Maybe it was just his short-sightedness or cluelessness, but it sounded like the same
Re: (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 n
Re: (Score:2)
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: (Score:2)
Cognitive dissonance is a wonderful thing.
Re:news flash (Score:5, Funny)
Cognitive dissonance is a wonderful thing.
No, it's a terrible thing.
But I want it. Badly.
Re: (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 o
Re: (Score:3, Insightful)
That's NOT the waterfall model.
Re: (Score:2)
I think the difference is that a lot of open source projects operate on a release-early-release-often philosophy
Huh? This took MySQL 3 years. Over one year in RC stage alone.
And, yet, it still has major bugs.
Re: (Score:3, Informative)
Re: (Score:2)
The old slow method (RASDIT - Requirements, Analysis, Specification, Design, Implementation, Testing) is hardly the waterfall method. Waterfalling is a relatively rapid cycle between implementing and testing in small stages, each stage feeding into the next, as a cascading series of waterfalls. The RASDIT software life-cycle states that after testing comes deployment, after deployment you go right back to the start and re-assess requirements. There is no direct feed between one cycle and the next (you re-us
Re: (Score:2)
All the references I can find and all the conversations I have ever had consider the waterfall model and RASDIT to be one and the same.
It is possible to write software this way and you will have a very high probability of producing robust, reliable, efficient code. It probably won't be maintainable, but it will very likely work and work damn well.
Sure, but by that time the requirements will have changed and your software will have no users.
Re: (Score:2)
Which is why the "maintainable" is such an important element. It's also why the full RASDIT cycle requires that on completion, you go back to the requirements gathering. The theory is that even though this method is slow, the software will converge on the users' needs as the amount of fresh code required will drop with each full cycle. It's entirely possible this is the methodology used in mission-critical systems, such as power stations, as you don't want to patch often and the requirements will change ver
Re:news flash (Score:5, Interesting)
Oh, I agree, every product that's ever shipped has shipped with bugs.
But you gotta put this all in perspective, some glib talk about how everyone is equal in the eyes of bugs just doesn't apply here.
First off, the context. We're talking about a database, your warehouse for your most valuable asset. This is not a place where you want to encounter mistakes, and caution is the word. You might hear excuses for some, but those people are idiots. This is /inexcusable/.
If you read the article, the things he says basically boil down to "this product is as stable as a house of cards and if you use it, treat it with all the care and caution you'd give a newborn child." I'd love to pick an excerpt from the article and copy it here, but it's just TOO RICH. Every single thing this "Monty" says would make your average MySQL apologist cringe, and makes normal people and DBAs stomachs turn.
Honestly, I think I'm gunna be sick. I don't care if MySQL is a good product or a bad product as such, I only use it for stupid things that do not matter at home, like my MythTV, never ever on anything that could be called "production." But having read this article and gotten a picture of what is, evidently, the thoughts of the minds supporting the creation and use of MySQL, it makes me ill. These people should just come out and say "there's no explanation we can give, this is crapware and we're really sorry if you got hosed by it. Don't use it at all if you aren't already." Instead this guy bends over backwards to explain how this broken database is actually quite useable, and ready for "general production" - how that's different from just "production" is clear: apparently "general production" refers to systems with zero value (less than my MythTV box, which will NOT be getting an update to this version).
Re: (Score:2)
I wish applications like that would stop using MySQL (and server-based databases in general), but I don't think there's a good alternative that isn't written in Java that supports multiple simultaneous connections. I like the approach used by the Java embedded H2 database engine [h2database.com] with its automatic server mode - you can open the database like a file, but the first client to co
Re: (Score:2)
While SQLite3 doesn't support true concurrency, it's generally good enough for things like MythTV. The locking is only slightly more clunky than MyISAM's.
Re: (Score:2)
That's only true if you use number of bugs as a measurement of overall quality.
Re: (Score:2)
I propose the 'bias' tag.
Re: (Score:2)
But seriously, if the quality of the programs is the same, then the openness alone should make the decision. As someone else pointed out, sometimes it takes a lot of work to find out there's a bug in a proprietary program, and then you're at the mercy of the corporation that made the program. When something's wrong in an open source program, the backers of the program are usually more open about it and you can go into the source and fix it yours
Re: (Score:2)
Second, there is an important difference between MySQL and a proprietary database solution. I don't have to pay any money for MySQL. If I try MySQL and it chokes on my database, all I am out is my time. If I buy proprietary, I am out money A
Re: (Score:2)
It is quite likely that the people who jump all over proprietary software that has a poor quality release are not the same people as the one's who are defending MySQL
A very valid point.
If I try MySQL and it chokes on my database, all I am out is my time.
And someone's data.
Not only that, it's the deception involved. They are calling it GA when it's anything but.
It's like if you ask me for directions, and I send you in the wrong direction and make it sound like I know what I'm talking about. You would probabl
Re: (Score:2)
You really can't deny that Slashdot is flooded with Linux/FOSS fanboys.
MySQL x.1 releases gives me the creeps (Score:3, Funny)
Re: (Score:2, Informative)
So, you're waiting for MySQL 5.11 for Workgroups?
Re: (Score:2)
Heh (Score:3, Insightful)
Depends on what you call "par", but for my values of "par", MySQL has never been there.
PostgreSQL has the same issues (Score:5, Interesting)
It just has them on a different scale and there's a different release. If you look through the past release notes for pgsql, you'll see that occasionally one release would come out with some horrific server crashing bug, get reported and get fixed.
Now, the timeframe is what is the key. For MySQL there are server crashing bugs that have been in place since 2003 or before.
For PostgreSQL, once such a bug is documented and reproduce-able, it is generally squashed in hours, days, and occasionally, for really complex problems, in a week or so.
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: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.
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.
MySQL join performance deficiency, 3 orders of mag (Score:3, Interesting)
Re: (Score:3, Informative)
If it returns 1, the column has data. If it returns 0, it's null.
Re: (Score:2)
Do you need the "and myBlob is not null"?
IIRC count(foo) returns the count of rows where foo is not null hence why a lot of the time where foo is a column name, it should really be * because the coder mistakenly thought specifying a column meant the db server has to do less work
Re: (Score:2)
Re: (Score:2)
select `id` from `table` where `blob_field` is not null
all tables should have an 'id' column (that's just standard practice), the above query will tell you which rows contain data.
Re: (Score:2, Interesting)
-Does it silently accept CONSTRAINTS other than FOREIGN KEYs and then not use them? ...
Why is ignoring FOREIGN KEYs okay? A constraint is a constraint, IMO.
Last I checked FKs worked, if you're using InnoDB, and then only kinda (no deferred checking, which is the SQL standard default).
Re: (Score:2)
You're comparing a GUI desktop to a DBMS.
What happens if KDE crashes and burns? You revert to a working version, or pick up some other desktop environment. If you're a novice, maybe you are in trouble. A desktop carries very little state -- and even less important state -- so switching back and forth doesn't cost much.
The costs of the scary problems Monty mentions could be arbitrarily high. If you lose data, or an application goes down, or you produce a wrong result and then base a decision on that wrong re