Locating the Real MySQL 335
An anonymous reader writes "In a blog post, Patrick Galbraith, an ex-core engineer on the MySQL Server team, raises the question: "What is the official branch of MySQL?" With Monty Widenius having left Sun and forked off MySQL for MariaDB, and Brian Aker running the Drizzle fork inside of Sun, where is the official MySQL tree? Sun may own the trademark, but it looks like there is doubt as to whether they are still the maintainers of the actual codebase after their $1B acquisition of the code a year ago. Smugmug's Don MacAskhill, who is the keynote at the upcoming MySQL Conference, has commented that he is now using the Percona version of MySQL, and is no longer relying on Sun's."
Selling an open-source software business? (Score:5, Interesting)
This calls into question whether it's viable to sell a business based on open-source software.
What did Sun buy exactly? Sales and support?
Re:PostgreSQL (Score:4, Interesting)
It really is a very good database. I just hope more projects start using it. And that more hosting companies will as well.
I am pretty sure that that MySQL still has better client slave replication "Like Slashdot uses" than Postgres. But I could be wrong.
Ironic (Score:0, Interesting)
Here we have the one shinning open source alternative to commercial databases and it is now faced with an identity crisis because they sold their name to a company about to be bought by IBM and outsourced to China and India.
So much for that open source licenses if the many people who worked and contributed all of their time to make MYSQL to make it an enterprise level application get shafted by the few.
We've seen many terrible forks in the past but this has to take the cake and usually thatâ(TM)s the last you hear of them we all know how well SUN maintains and contributes to there open source projects as it is. It's been awhile but the last time i checked their STL library it was horribly behind. Now imagine IBM.
Time for postgress, besides it has much better GIS support.
Re:Enough already! (Score:5, Interesting)
Actually the subject is how your data is supposed to be used.
MySQL users see the database as a program persistance layer. I am not sure WHY they are using something that pretends to be a relational database, but they are. It is the single-app approach (one app, one database).
The PostgreSQL crowd sees data and application as being separate issues. The data in theory should be able to be managed in any of a hundred different applications, all hitting the same database, without causing the nightmares in QA that this sort of thing creates in MySQL.
So is the program what is important? Or is the data there to be used by many programs?
MySQL works OK for one-app databases and many people think that is all that is needed. It breaks down outside that area, however.
Re:Enough already! (Score:2, Interesting)
Well, we discovered that "elite" is mostly hubris.
Re:Not a good precedent (Score:3, Interesting)
Actually the message it sends is you can not take control just by buying out one piece of the open source world. For the record Sun is going through the same thing with Open Office. Sun really doesn't understand open source.
The official branch is where ever the big distros decide to pull from.
Re:PostgreSQL (Score:5, Interesting)
Why do you like it so much? Is it faster with large datasets? Does it support backups/replication/some other great to have feature?
I'm pretty familiar with MySQL, but I've been thinking about branching out to PostgreSQL lately as I've seen a few jobs that prefer it. I'd just like some real reasons why I should prefer it, as well as any "gotchas" that might be important for a MySQL user to know. I've never had a problem with MySQL, but most of the projects I've used it on have been fairly small.
Re:PostgreSQL (Score:5, Interesting)
One of the reasons I like PostgreSQL is it is more like Oracle.
If you're doing a migration from Oracle, especially one that has a lot of pl/sql functions. Here's some good advice for converting pl/sql to pl/pgsql [redhat.com].
Also, going from PostgreSQL to Oracle seems easier as well. With PostgreSQL you can use more Oracle like features so if you need to move to Oracle, you can take advantage of some of it's advanced features instead of migrating simple tables and sql statements.
Sun was actively involved with PostgreSQL before they bought MySQL. I was really dissapointed with their decision, especially at the price.
My guess is they weren't really buying MySQL for the technology, they were buying it for the community. Overnight, a ton of MySQL users and developers were part of Sun's open source community. Building communities takes time and Sun was having a hard time doing it with some of their projects.
All it seems they did though is fund MySQL forks. Kinda messed up for the MySQL developers to do that but we don't know all the details.
$1 billion dollars could have funded a lot of improvements to PostgreSQL better clustering, replication, visual tools, and more. A better PostgreSQL could hurt Oracle more than buying MySQL. After Ellison announced he'd be moving his developers from Solaris workstations to Linux workstations, it could have been a nice comeback.
It also seems that the switch form solaris to linux might not have been developer driven [intel.com]. Even MS knows you have to keep your developers, developers, developers happy.
Re:Great Sun Acquisition (Score:3, Interesting)
There's been plenty of speculation that Sun was interested more in MySQL from the sales side of things than from the technology one. MySQL had figured out how to sell open-source solutions to people for money successfully, something Sun would like to do more of. The high-profile engineers can jump to other projects on a whim, that doesn't necessarily mean they've lost what they wanted out of the purchase.
Re:Enough already! (Score:5, Interesting)
You forgot to broaden your scope. Otherwise, you are correct.
Your database is almost literally your company. It should reflect your way of doing business--any moderately skilled developer should be able to walk into an orginization they know nothing about and using only the database schema, infer pretty much what the company does, and how it does it.
You can always fix flawed software design, but it is almost impossible to fix a flawed database design. Do your database wrong, the growth of your company will be hindered. Do it right, and your company will flourish. No joke.
*Cough* (Score:3, Interesting)
I ran into that little nugget when I migrated webapp database from MySQL to PostgreSQL.
As with any webapp, the software would let you create an account on the website. Can't have duplicate users, so the code would check to see if the username existed.
SELECT count(uid) FROM users WHERE username='coryking';
Got "0"? Well, the user is okay... well, at least on MySQL. In MySQL, "coryking", "CorYKING", and "CORYKing" are all the same. As I would soon discover, that assumption is *not* true on PostgreSQL.
Result? A month after the migration, I discovered "unique" accounts for "coryking", "CoryKING" and "CORYKING". Obviously, this can't be. All usernames in webland are case-insensitive. Thankfully, there was only a handfull of these "unique" users to clean up. Had this been left alone for a year, I'd have quite a cleanup on my hands!
Moral? MySQL is case-insensitive, PostgreSQL isn't. Honestly, the proper thing is to be case-sensitive and I assume pretty much every database besides MySQL is case-sensitive. But you have to make your unique index on LOWER(username) instead of username--oh wait, except you can't do that in MySQL cause they dont support indexes on functions... sucks for them!
Good times.
Re:PostgreSQL (Score:2, Interesting)
The "headache" is that it's secure by default and you need to edit pg_hba.conf (allowed IPs) and postgresql.conf (listen port) to get it opened up to the world. In other words, people want it to be insecure, and it takes effort to make it so. Sad that editing a line in two different config files once during the life of a database is now deemed "a headache" and a major reason not to use that database.
Maybe they're having a hard time finding it in Synaptic? Here's a hint, guys: it's sorted "alphabetically" and there's a search button on the top.
Otherwise, there are absolutely NONE of the headaches that come with Oracle: the licensing, the immense resource requirements, the bloated platform it brings along with it (several hundred megs for a database?! WTF?) It really is the best of Oracle without Oracle's headaches.
Oh -- and the killer features for me? ACID, MVCC, plpgsql and plperl, user-defined functions long before MySQL had them, a user and developer community that is second to none, a strong focus on doing it "right"...
Re:PostgreSQL (Score:3, Interesting)
Why do you like it so much?
It works by default.
MySQL has, in my experience, a tendency to weirdness. Examples abound:
These are just off the top of my head, and not all that are there. MySQL has way more non-functionalisms. All of the above have impacted development/stability for projects I've been involved in.
So - I like PostgreSQL because it works. Better performance for complex queries is nice - but I'm mostly interested in the fact that it for the most part just works by default.
Eivind.
It isn't fud (Score:3, Interesting)
It is a bit of lore. It is a difference between the two products that you might not have considered before migrating that you better take into account. I didn't even think about it, and I almost got into a huge jam as a result.
Except that breaks unicode. Characters aren't byte[]'s, they are characters.
The proper answer is to use the correct collation. The only thing is PostgreSQL doesn't really do that kind of thing yet.
My solution was to create a new datatype based on this example [varlena.com] that uses case-insensitive operators. Instead of using the "varchar", I my spiffy new, case-insensitive "ltext" version. Fully indexable too!