Slashdot Mirror
MySQL Readies Release Candidate For 5.1
Anonymous Dolphin writes "MySQL has released plans for a final RC for the MySQL 5.1 server. Monty Widenius, the CTO and founder of MySQL, has put up a request for more feedback from the community. You can get the latest RC here. Please help with the testing of 5.1 and report your bugs here."
MySQL XML Functions.
Tweet, tweet.
So now mysql can handle two concurrent inserts? Nice! Except for the fact that this new amazing option is incompatible with replication. MySQL is going to become a real database. Any time now...
___
If you think big enough, you'll never have to do it.
You haven't kept up. Sun stated that nothing was going to change with the license. The "closed source" portion had already been released under the gpl and Sun said it would stay that way. In Fact they just moved from the closed source bitkeeper to bazaar for source code control, allowing anyone to track their progress.
PostgreSQL is a fine Database as well. MySql just seems to be used more in web environments.
Well.. maybe. Or Maybe not. But Definitely not sort of.
This isn't really true of an upgrade from Mysql 4.x -> 5.x. MySQL changed some things (notably their JOIN syntax) to make them more compliant with the ANSI standards. So assuming you're dealing w/ PHP/MySQL programmers that only knew the MySQL way to do joins, their applications may break on upgrade.
For more information, see the section entitled "Join Processing Changes" here:
http://dev.mysql.com/doc/refman/5.0/en/join.html
It was interesting to see Sun's reaction.
Apparently, MySQL AB (prior to purchase) were the ones contemplating making the move to more proprietary tools. It was set in motion and left on the table, then Sun purchased them.
Sun basically said "We have no need to put this in play, we don't make our money from a single product like MySQL AB did .."
A lot of people Criticized Sun for the idea, however the idea was the brainstorm of MySQL AB, not Sun.
I would like to use MySQL instead of Postgres - it's easier for me to install, maintain, and just plain understand. I don't like how PG does things a lot of the time and find it needlessly complex. But because MySQL lacks the seemingly basic ability to store a timestamp with better than second accuracy, I can't, because I have to store log events which are often more than one a second - much more - and I need to know exactly when. Milliseconds would be fine, microseconds would be great.
MySQL currently recommends some ridiculous hack where you strip the sub-second information from the time you send it and store it in another column, then write some kind of view which combines them back. What? I am not doing that to implement what I consider to be basic functionality! Do you remember how my motivation for switching is because I want things to be simple? Writing weird multi-column time recombination hacks is not my idea of simple.
Replication improvements, XML parsing, great features all - but please just give us timestamps with accuracy better than a second? A lot can and does happen in less than a second and I need to be able to log it with accuracy!
Let my new 7-digit UID be a lesson to all - write down your passwords.
The only thing that I look forward to in 5.1 is the addition of triggers for non-root users. I've fought many a battles with hosting providers wanting to charge me upwards of $120/hr to put my triggers in place as root because MySQL didn't allow regular users to run it.
Now, finding a hosting service willing to upgrade to 5.1 within a year after it's released is going to be a new bat
Change is inevitable, except from a vending machine -- Robert C. Gallagher
And anyone who likes to bitch about MySQL deserves an Oracle bill.
Or they could use Postgres...
It's official. Most of you are morons.
Your response was condescending and presumptive.
Your response is paranoid and childish. Sometimes you have to hear things you don't want to hear. The AC's response is actually funny and accurate. By in large, most MySQL users are children when it comes to relational databases. You don't have to be a PostgreSQL zealot to recognize that fact. Simple fact is, MySQL is the low rung on the SQL ladder. All DBAs worth respecting understand this simple fact. In other words, what you assume to be zealotry can just as likely be a factual statement by a knowledgeable person.
Just because you heard something you didn't want to hear doesn't mean it was delivered by a zealot. The fact that you're so easily confused by such a fact is a significant indicator the AC's comment was correctly targeted (you're too close) at you. Your response also implies you are in fact a MySQL zealot. Otherwise, why so easily offended by a comment which was obviously presented with levity, by an AC, in a trollish manner. Getting upset about that is just plain silly.
At the end of the day, with so many excellent relational databases available at zero or little cost, choosing MySQL as your database speaks poorly of you. Just about any database is better than MySQL. Imagine a friend bringing home a cheap Chinese made, Yamaha reproduction and declaring they are tired of "zealots" pointing out that better bikes exist. Well, your friend might be tired of hearing it, but it doesn't change the facts. It doesn't take a zealot to point out that bike is a complete PoS; and without regard to zealotry, better options exist. At least with a bike, you can defend such a purchase from a cost perspective. No such hand hold exists when it comes to the field of freely available databases; almost all of which are better than MySQL.
Lastly, please don't forget that one need only be knowledgeable about relational databases to dislike MySQL. Zealotry need not be a factor.
That's a bit harsh and unrealistic.
In Real Life (tm), you don't always have that choice: sometimes you take what's given to you and roll with it, sometimes you have to use what you know best to get the job done.
I use both nowadays: I do feel more comfortable with MySQL (mainly the tools, auth. mechanisms) because for many years, it was the only option available: host didn't provide Postgres support, xyz application didn't support it, or I personally couldn't justify the risk/learning curve for a tight project.
Postgres may be "superior" to MySQL, but that doesn't mean it's the right choice all the time.
body massage!