The Ups and Downs of MySQL AB

Wannabe Code Monkey writes "Forbes has an article about a recent MySQL deal with SCO and the reaction from the open source community: "It's been a rough week for Marten Mickos, the chief executive of open source database maker MySQL AB. First his most dreaded rival, Oracle acquired a company that supplies a key piece of MySQL's software, a move that could make life difficult for Uppsala, Sweden-based MySQL, which has the most popular open source database. If that wasn't bad enough, Mickos is being denounced as a traitor by noisy fanatics in the open source software community because last month he dared to make a deal with SCO Group, a company reviled by fans of Linux and other open source software.""

Groklaw Interviews MySQL AB CEO Marten Mickos

[anandpur]

http://www.groklaw.net/article.php?story=200510112 11450706 [groklaw.net]

* no money went to SCO from MySQL, so MySQL is not supporting SCO financially
* it was SCO seeking out the partnership, not the other way around
* MySQL had stopped supporting SCO in 2004
* MySQL did not put out the press release about the partnership. Mickos did provide a quotation for the press release however. Here's the press release in question, taken from MySQL's web site. http://www.mysql.com/news-and-events/news/article_ 948.html [mysql.com]

Re:What piece are we talking about?

[lmfr]

Oracle acquired Innobase [slashdot.org], maker of InnoDB.

a key piece ??

[six]

Although InnoDB is quite a niece piece of work, I wouldn't call it a key piece of the MySQL server software. It is just one of the *many* storage backends supported by MySQL, and it's not by far the most used (99% of the MySQL installs i've seen only use the internally developped MyISAM storage engine which btw is the default one ...

And btw, people who need transactions and advanced features tend to use postgresql instead of mysql+innodb ...

Re:Well now

[codegen]

LAMP becomes LAPP

Re:a key piece ??

[Just Some Guy]

I wouldn't call it a key piece of the MySQL server software.

I would, because it was responsible for most of the "new" features MySQL was bragging about.

And btw, people who need transactions and advanced features tend to use postgresql instead of mysql+innodb .

You misspelled "will have to" (excepting Firebird et al).

Re:INDEMNITY? Will SCO sue us some day?

[jadavis]

PostgreSQL. A short list of benefits:
- MVCC reduces need for locking, often called "better than row-level locking"
- Also has row level locking
- ACID compliant
- transactions, and savepoints (which are SQL nested transactions)
- point in time recovery (PITR) allows "time-travel" and parallel timelines. It's a little much to explain here, but if you encounter a problem and notice it a week later, you can go back in time, prevent the problem, and replay everything else that happened that week. All the good and none of the bad from a sci-fi book :)
- VERY extensible: you can make user-defined functions in any of PL/pgSQL, PL/perl, PL/python, PL/java, C, or SQL. And if that's not enough, you can write another procedural language to support your favorite language.
- You can make a user-defined aggregate function using any of those languages.
- User-defined types
- triggers
- views
- subselects
- query rewriting rules (which can be used to make any view updatable/insertable)
- constraints
- good, well-maintained, and BSD licensed replication software available.

New in 8.1 (which is beta now):
- Two-phase commit (2PC)
- IN/OUT/INOUT parameters to functions
- rudimentary table partitioning
- bitmap index scans
- autovacuum intelligently automates a long standing maintenence procedure, making the database easier to administer.
- SQL ROLES
- more options for row-level locking

Re:MySQL has some business strategy...

[jadavis]

I can only assume you grossly misused PostgreSQL or some other software on the machine. PostgreSQL has a legendary reputation for reliability and stability, which has held up perfectly for me for years (no postgresql failures ever).

And if a disk crashes, you can hardly blame PostgreSQL. PostgreSQL has several great online backup systems available: Slony-I (repliaction), point-in-time recovery (PITR), and pg_dump. Use them.

You are also the first person I've heard describe PostgreSQL as a "memory hog".

My guess is that you made no attempt to diagnose the problem. I doubt your problems are related to a PostgreSQL bug. You could have reported your problems on pgsql-general, and I'm sure people there would have helped you as long as you provided good information.

Re:Groklaw Interviews MySQL AB CEO Marten Mickos

[Saeed al-Sahaf]

Sure. Yes. Well put.

But remember EV1? This SCO storm will pass. What will not, and what should be more important to those who use MySCO is the InnoDB buy-out. MySQL missed that opportunity, and will pay for it. Indeed it may be their downfall. But in a few weeks, the SCO issue will have passed.

Re:Confused about licensing

[bani]

You mean you were actually convinced by the marketspeak? I saw right through it -- mysql is saying what sco wants to hear, not what mysql actually believes.

Re:Larry Ellison

[IANAAC]

MySQL only indirectly competes with Microsoft. But MySQL is directly competing with Oracle.

I don't personally believe you're correct on either account.

Have you ever actually tried converting a MySQL app (written by any Joe-Schmoe) to either MSQL or Oracle? It's a damn near Herculean effort. MySQL is so non-standard WRT the rest of the SQL world most orgs would consider it not worth their time.

A complete re-write is in most cases necessary. On the other hand, Any other reasonably SQL compliant DB wuld be at least doable. Granted, there are always going to be optimizations, but standard SQL gets you a fair bit along the way. Something the MySQL lacks. Really.

What's with the back-ticks anyway?