David Axmark Resigns From Sun
An anonymous reader writes "From Kay Arno's blog we see that David Axmark, MySQL's Co-Founder, has resigned. This comes on top of the maybe, maybe not, resignation of Monty. We saw earlier this year that Brian Aker, the Director of Architecture, has forked the server to create a web-focused database from MySQL called Drizzle. The MySQL server has been 'RC' now for a year with hundreds of bugs still listed as being active in the 5.1 version.
What is going on with MySQL?"
It allows for disagreements to be resolved by disagreeing, even when there are corporations with lots of lawyers involved.
You can still fork it. No easy corporate lock down is possible.
----- "Profanity is the one language that all programmers understand."
How long until Netcraft confirms that Sun is dieing?
Anybody want my mod points?
Has anyone here used Drizzle?
I'm about to start a new web project and I get to choose the DB. I'm concerned over the lack of stored procedures though. My last big project used SP's for everything and honestly, while initial coding was a pain, in the long run it was a huge benifit.
I need a lean and mean webDB, so, if not Drizzle, does anyone have other recommendations?
http://www.jpipes.com/index.php?/archives/263-So-Long,-and-Thanks-for-all-the-Fish.html
Interesting comment at the bottom (#11):
"Glad to hear you'll be working full-time on Drizzle. Even if you didn't escape Sun.
I can't imagine who would want to be a community manager under the current situation, though. Good luck to Giuseppe."
"How about the "bad connection" issue where the database server due to no reason obvious to the developer will count to ten and then just refuse new connections? How about when MySQL trips over itself and locks it's own tempfile? How about the admin gui that pretends to let you change parameters but really doesn't?"
I've developed, debugged, administered, and administered MySQL databases for nearly a decade now, and I have never seen any of those issues you complain about.
"How about MySQLs abmyssal speed once it has to deal with larger tables?"
The InnoDB storage engine uses clustered indexes and is actually pretty good with large tables. Combine that with the partitioned table support in MySQL 5.1 and large tables are quite manageable. I have one OLTP application with well over 300M rows, and the server runs fine even though it is on commodity hardware.
"but there is no use in pretending like there aren't any problems ..."
Indeed, but they weren't what you mentioned here. I am looking for better CPU utilization on multicore systems, semi-synchronous replication, parallelized replication, better foreign key performance, and better join algorithms. Many of these features are planned of course but I want them now.
501 Not Implemented
I've definitely seen mysql use up tons of memory before for no apparent reason. Trouble is it did this at a customer's site on a live machine with lots of users.
My ex-boss insisted on MySQL - whereas me and my colleague were pushing for postgresql instead. Oh well...
Postgresql has its fair share of problems, but looking at the Postgresql and MySQL mailing lists and bug reports, I'm more comfortable with the Postgresql problems.
Stuff like this scares me:
"ORDER BY DESC in InnoDB not working"
http://bugs.mysql.com/bug.php?id=31001
So it might actually be a good thing if MySQL fades away.
(which reminds me of the error message when it crashes every once in a while: MySQL has gone away :) )
The problem with MySQL is the "brochure" looks very nice to the PHBs.
But when you get to the details, a lot of the advantages/features are mutually exclusive.
Want fast simple selects - MyISAM
Want fast single user inserts - MyISAM
Want fast concurrent inserts - InnoDB
Want fast concurrent inserts to tables with an "autoincrement" column - better look at this http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html
Sun doesn't, but if you live in the Java world have you looked at Derby recently? We started out using it as an authentication database embedded in an app, and are now making more and more use of it. It supports transactions and hundreds of simultaneous connections, has very flexible configuration, and supports up to about 50Gbytes of storage. The last alone makes it more useful in many applications than the free versions of MS SQL Server. There are many applications currently running on MySQL which (in my opinion) would benefit from migrating to a tightly coupled all-Java solution. The Derby footprint is tiny, database backup and failover is now supported, and you can work with anything from the command line tool to the usual studio type applications. It has taken me 4 years to become a convert, after 8 years of MySQL, but now in the latest release I love it.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."