Slashdot Mirror
Has MySQL Forked Beyond Repair?
snydeq writes "Fatal Exception's Neil McAllister questions the effect recent developments in the MySQL community will have on MySQL's future in the wake of Oracle's acquisition of Sun. Even before Oracle announced its buyout, there were signs of strain within the MySQL community, with key MySQL employees exiting and forks of the MySQL codebase arising, including Widenius' MariaDB. Now Widenius' Oracle-less Open Database Alliance adds further doubt as to which branch of MySQL will be considered 'official' going forward. 'Forks are a fact of life in the open source community, and arguably an entirely healthy one,' McAllister writes. 'Oracle just better hope it doesn't end up on the wrong side of the fork.' To do so, he suggests Oracle will have to regain the the trust and support of the MySQL community — in other words, 'stop acting like Oracle.'"
Postgresql has a terrible marketing and image, mysql doesn't.
Well they want to be compatible with existing MySQL versions as Monty has stated and not be a fork but they also want to fix broken functionality on the backend that SUN has been unwilling to do thus far. MariaDB from my understanding is just a community version but they would like to see their commits go up to Oracles version as well.
If they make improvements and Oracle refuses to be part of the community, then guess who is going to have the better version in the long run? I'm putting my money on that community of developers rather than the company with the overblown ego. We all know how companies with overblown ego react to the open source community after all.
This is my sig. There are many like it but this one is mine.
Clearly this is a troll but regardless of all other features that MSSQL may have that MySQL doesn't there is one thing that is missing: LIMIT.
Perhaps it's because LIMIT isn't ANSI SQL? Before SQL-2008, you were supposed to use ROW_NUMBER() for that, which MSSQL does support. And no-one supports SQL-2008 yet.
I've heard the arguments that postgres is as easy as MySQL, and they're bullshit.
Lets see:
Postgres has no good GUI applications that can compare with MySQL's
Why you need more than one is beyond me. Isn't Pgadmin enough?
their command line application is just as good in its own way
Well, ok. Whatever 'in its own way' means.
and the market share that ensures you need to google multiple times to find the info you're looking for.
Postgres has some of the best documentation of any open source project I've seen. Sure, MySQL is good as well, but lets not spread bullshit here.
Installing postgres is also a nightmare compared to MySQL.
You mean in a download-the-msi-and-double-click-on-it way, or the apt-get-install-it way?
To sum up: free > $millions, easy > full-featured (in many circumstances).
Well, it's fully-featured, but not necessarily all of those features at the same time. Try doing full-text indexing on a database with foreign-keys on it in MySQL sometime.
There is nothing interesting going on at my blog
MSSQL supports the (cumbersome) ISO rownumber operator doesn't it? The syntax to apply a limit is a bit bodgy, but it does work neh?
This gets rows 100 through 200.
SELECT * FROM (
SELECT
ROW_NUMBER() OVER (ORDER BY key ASC) AS rownumber,
columns
FROM tablename
) AS foo
WHERE rownumber > 100 and rownumber = 200;
Wikipedia
Is 99% cached content, served as effectively static files
Google
Has some developers who have it installed; none of their major services are based on it
Facebook
According to the video of how it works, is basically a graph database, on top of a giant key:value table, on top of memcache, on top of mysql -- ie, they do their best to avoid actually hitting the database, and when they do, they only make use of the most basic functions (and it isn't even good enough for that, so they're working on a replacement)
Twitter
While large, it's hardly complicated in terms of database schema, and it /still/ falls over all the time :P
The other sites, I've never seen any behind the scenes reports on.
While "we have at least one copy of mysql installed somewhere in our organisation" is common, "we are using mysql as the central database for our heavily stressed mission critical systems, and it works great" is much rarer :-P
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
Just once? I usually get modded "funny" when I'm serious, and "informative" when I'm joking.
/. mods are very bored individuals. It gives them something to do. They're not like us, the /. posters, who are intelligent, thoughtful, handsome, and socially adept.
Most
Entomologically speaking, the spider is not a bug, it's a feature.
In comparison? Yes. When you're doing simultaneous writes from multiple threads, SQLite's lack of fine-grained locking kills performance.
A couple of months back I did some benchmarking of MySQL and SQLite3 as possible storage backends for a website. The test load was a task consisting of two SELECTs, an UPDATE, and an INSERT. With only one or two simultaneous clients, SQLite3 was faster. With three clients, they were tied. At 50 clients, SQLite3 was taking over 100 times longer than MySQL.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
PostgreSQL scales well, but is fairly slow on average.
Really? Because any recent review of Postgres shows that it stomps the pants off MySQL in all cases except very simple queries against very small tables. (And really, who gives a !@#% about that scenario?)
Also....
1) It's data validation is excellent.
2) It's extremely stable. In YEARS of working with it, I've had ZERO integrity issues despite managing rather large data sets.
3) Particularly important: it maintains good performance as the query complexity soars. While it can take a bit of tuning, I've done 12 table joins with combined inner, outer, and subqueries and millions of records, with an average return time of around 0.2 seconds. The statement alone was two pages, printed form, on a single-core Athlon 64 with ATAPI drives and 1 GB of RAM.
4) It's FREE FREE FREE!
5) It includes excellent near-realtime replication. (functionally analogous to MySQL replication, which is nice when it works, but since it usually doesn't, well...)
1994 called. It wants its stale information back.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
And then there's the increment functions. MySQL is a bit lacking, with only AUTO_INCREMENT and LAST_INSERT_ID. SQL Server has a similar setup to MySQL using IDENTITY(start, step) and SCOPE_IDENTITY(). But PostgreSQL uses that atrocious monstrosity of SERIAL data types and a damned Sequence object.
PostgreSQL seem to have copied that bit from Oracle, which also uses sequences. But sequences are actually superior, and here's why.
With sequences, you can emulate auto-increment behavior easily (you use the NEXTVAL or whatever the syntax in a specific implementation is, right in your INSERT). On the other hand, with sequences, you can generate the IDs first, and then generate a bunch of INSERTs with those IDs, with only two roundtrips: one for SELECT NEXTVAL - for as many records as you want - and another for multi-record INSERT. Why would you want a bunch of IDs? When you are batch-inserting records into a bunch of tables that reference each other (e.g. 10 records into table A, each of which has 10 new child rows in table B, each of which has 10 more new rows in table C). In MSSQL with auto-generated keys, you have to go about it that way:
1. INSERT records into A and retrieve the generated keys.
2. Use retrieved keys to generate INSERTs for new records in B; retrieve generated keys.
3. Use retrieved keys to generate INSERTs for new records in C.
For more tables in the hierarchy, you do more roundtrips. Now the same with sequences:
1. Request generation of keys for all records you'll be inserting, and retrieve generated keys.
2. Generate INSERTs for all new records using retrieved keys.
And it doesn't matter how deep the tree is, it's only 2 batches.
Of course, for MSSQL you can do away with generated keys completely, and use GUIDs, which can be generated on the client in the first place. But that makes indexes that much bigger, and queries that much slower...
nd heaven help you if the Sequence gets out of sync
This bit I don't understand at all. What do you mean by "sequence gets out of sync"? It's not really in sync with anything, it's just a simple counter that's guaranteed to safely produce unique incrementing values even for concurrent requests.
And one more fork in the making that looks like it is going to have the same impact as XFree/X.org eventually, if not bigger: EGLIBC
Actually not really true. Postgres in the early days always was way more stable than MySQL, the speed however was less, because it always supported transactions, while MySQL started as an ISAM system with some sqlish language on top of that. But I never ever recall having the problem of corrupted data on postgres not even in version 6. The main issue was simply, that there was no decent windows port and postgres had to rely on Cygwin which made the db slow und unstable while it was not!
Add to that that early PHP versions were hardcoded against MySQL, and PHP as well got loads of momentum!
Things have changed by now. While the MySQL quality still is questionable, PostgresSQL has accellerated tremendously and also has a native windows port and good installation and UI maintenance tools but the problem persists while being leagues better, and believe me I have seen big installations where postgres chugs along happily never failing their users, MySQL still has the mindshare.
If you are looking for a real enterprise ready db in the OSS area PostgreSQL is the way to go!