Slashdot Mirror
Locating the Real MySQL
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."
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?
There's no -1 for "I don't get it."
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.
LedgerSMB: Open source Accounting/ERP
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.
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.
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. Even MS knows you have to keep your developers, developers, developers happy.
Dual Opteron < $600
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.