Slashdot Mirror

You've obviously never worked for the company, then.

One of the first things a new hire learns (if he doesn't know it already) is that the official pronunciation is my-ess-cue-ell.

If they have a decent transactional database, they'd be keeping a record of everything that happened.

They don't

I'm no DB expert, but much of the hate for MySQL seems (at least a little) unjustified. For one, their customer list is fairly impressive.

Wikipedia use them, which isn't exactly something to sniff at.

According to MySQL's site, Oracle and MySQL comprise around 52% of the of all deployed databases. If you don't understand that authorizing a deal which would enable a company which already controls 47% of the market share to form a company that controls such a dominant stake in the database market is bad for the market then you would most certainly benefit from investing a couple of minutes thinking about this subject.

You must work for Oracle. MySQL is a perfect choice for grownup Enterprises. Please check out their customer page, you'll see mega grownups like EMC, Facebook, etc... http://www.mysql.com/customers/?id=287

What makes you think that relational calculus can't be extended to support spatial information? After all, it's just another kind of index.

named sub-queries

What do you think stored functions and procedures are?

No, the BSD allows me to open or close my source code, that is control.

No, the BSD allows the licensee to open or close your source code at will, and to add arbitrary restrictions.

You the original author can place your code under the GPL and withdraw source or change the license for future distributions any time you want.

The GPL does not prevent you from closing the code at a later date, as long as you don't accept contributions licensed under the GPL.

A good example of this would be MySQL. The code is GPL, but they also sell commercial licenses. If you receive MySQL under a commercial license, you get special rights that are not included in the GPL (but are also restricted in other ways).

MySQL AB can change the license of code they distribute at any time, because they own copyright, and in order to contribute code to MySQL, you have to sign over your rights to MySQL AB.

It doesn't really matter what they use it for, now does it? The fact that they choose to use MySQL at all shows they put an amount of faith into it. You don't store data in a database because you want to lose it, right?

But, to answer your question, a quick Google learns Facebook, YouTube and Wikipedia store all of their important data in MySQL databases. I know Google doesn't use MySQL for searches, but they do store other stuff. I'm not sure what Nokia does, but they do seem to like MySQL a lot.

Sorry, I was looking at the mysql client code, not the server code. The client code has these FOSS exceptions:

http://www.mysql.com/about/legal/licensing/foss-exception/

Wrong. You made the same mistake with the Linux kernel ( http://slashdot.org/comments.pl?sid=1406005&cid=29765325 ). The GPL states that:

"If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation."

The MySQL source is released explicitly under version 2 of the licence and *not* "any later version". Let's pick a random MySQL source file and read the copyright notice at the top:

From ./storage/myisammrg/myrg_rkey.c

"/* Copyright (C) 2000-2003, 2005 MySQL AB

      This program is free software; you can redistribute it and/or modify
      it under the terms of the GNU General Public License as published by
      the Free Software Foundation; version 2 of the License.

      This program is distributed in the hope that it will be useful,
      but WITHOUT ANY WARRANTY; without even the implied warranty of
      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
      GNU General Public License for more details.

      You should have received a copy of the GNU General Public License
      along with this program; if not, write to the Free Software
      Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */"

Older versions of MySQL weren't tied to the GPL2. You can read the statement from when this was changed at http://blogs.mysql.com/kaj/2006/12/22/mysql-refines-its-gpl-licensing-scheme-under-mysql-50-and-mysql-51/

It's reasonable to make mistakes, but to make them repeatedly in such a condescending, impertinent tone is outrageous. Please stop telling people that you can re-licence something under the GPL3 by virtue of the fact that it is released under the GPL2 - you can only do so if the copyright holder adds the "and any later version" statement.

Sun's MySQL page states ( http://dev.mysql.com/downloads/mysql/5.4.html ) that it is licensed under GPL and refers you to the following URL:

http://www.gnu.org/licenses/old-licenses/gpl-2.0.html

Which clearly states it can be licensed using any newer version of GPL by anyone who wants to do so.

I'm sorry, you were claiming something about what RMS was stating? I lost track after realizing you had no idea how it was licensed.

They have already killed mysql 6.0 "MySQL 6.0 was not developed beyond Alpha status and new releases have not been made for some time, so the manual has been withdrawn as well."

http://dev.mysql.com/doc/refman/6.0/en/index.html

Wrong. We have NOT 'killed' 6.0, but it not going to be the focus of our development for a while, and we won't do any more official 6.0 releases for some time to come. But we HAVE moved it to the back burner, so to speak.

If you really want 6.0, you can get it right here:

https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase

No guarantees right now as to how well it'll build and run on any given day; I think I last built it last Tuesday or Wednesday, and it seemed to do okay, but of course YMMV. That being said, go get the code and knock yourself out.

In the meantime, we're backporting what we think are the best bits of 6.0 to 5.X.

so what is next ?

You'll find some answers to that question here...

http://dev.mysql.com/doc/refman/5.1/en/mysql-next-series-plans.html

And here...

http://dev.mysql.com/doc/refman/5.4/en/

And what's this? The latest release, from less than a week ago:

http://dev.mysql.com/doc/refman/5.4/en/news-5-4-3.html

That's the clone-off date, BTW. Binaries should be available here

http://dev.mysql.com/downloads/mysql/5.4.html

in a few days.

5.x on the death row

I think that's a bit of a stretch. Why don't you see what we say about it on the site?

http://www.mysql.com/about/legal/lifecycle/

NB: We have a choice between (a) honouring the policies on this page and (b) breaking contacts with paying customers.

Can you guess which of these we're more likely to do?

maybe is time to move to postgresql , firebird ...

That's one of the reasons why it's called Free Software -- you're absolutely free to move to something else if you like, and we wish you every success with it if you choose to do so.

They have already killed mysql 6.0 "MySQL 6.0 was not developed beyond Alpha status and new releases have not been made for some time, so the manual has been withdrawn as well."

http://dev.mysql.com/doc/refman/6.0/en/index.html

Wrong. We have NOT 'killed' 6.0, but it not going to be the focus of our development for a while, and we won't do any more official 6.0 releases for some time to come. But we HAVE moved it to the back burner, so to speak.

If you really want 6.0, you can get it right here:

https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase

No guarantees right now as to how well it'll build and run on any given day; I think I last built it last Tuesday or Wednesday, and it seemed to do okay, but of course YMMV. That being said, go get the code and knock yourself out.

In the meantime, we're backporting what we think are the best bits of 6.0 to 5.X.

so what is next ?

You'll find some answers to that question here...

http://dev.mysql.com/doc/refman/5.1/en/mysql-next-series-plans.html

And here...

http://dev.mysql.com/doc/refman/5.4/en/

And what's this? The latest release, from less than a week ago:

http://dev.mysql.com/doc/refman/5.4/en/news-5-4-3.html

That's the clone-off date, BTW. Binaries should be available here

http://dev.mysql.com/downloads/mysql/5.4.html

in a few days.

5.x on the death row

I think that's a bit of a stretch. Why don't you see what we say about it on the site?

http://www.mysql.com/about/legal/lifecycle/

NB: We have a choice between (a) honouring the policies on this page and (b) breaking contacts with paying customers.

Can you guess which of these we're more likely to do?

maybe is time to move to postgresql , firebird ...

That's one of the reasons why it's called Free Software -- you're absolutely free to move to something else if you like, and we wish you every success with it if you choose to do so.

They have already killed mysql 6.0 "MySQL 6.0 was not developed beyond Alpha status and new releases have not been made for some time, so the manual has been withdrawn as well."

http://dev.mysql.com/doc/refman/6.0/en/index.html

Wrong. We have NOT 'killed' 6.0, but it not going to be the focus of our development for a while, and we won't do any more official 6.0 releases for some time to come. But we HAVE moved it to the back burner, so to speak.

If you really want 6.0, you can get it right here:

https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase

No guarantees right now as to how well it'll build and run on any given day; I think I last built it last Tuesday or Wednesday, and it seemed to do okay, but of course YMMV. That being said, go get the code and knock yourself out.

In the meantime, we're backporting what we think are the best bits of 6.0 to 5.X.

so what is next ?

You'll find some answers to that question here...

http://dev.mysql.com/doc/refman/5.1/en/mysql-next-series-plans.html

And here...

http://dev.mysql.com/doc/refman/5.4/en/

And what's this? The latest release, from less than a week ago:

http://dev.mysql.com/doc/refman/5.4/en/news-5-4-3.html

That's the clone-off date, BTW. Binaries should be available here

http://dev.mysql.com/downloads/mysql/5.4.html

in a few days.

5.x on the death row

I think that's a bit of a stretch. Why don't you see what we say about it on the site?

http://www.mysql.com/about/legal/lifecycle/

NB: We have a choice between (a) honouring the policies on this page and (b) breaking contacts with paying customers.

Can you guess which of these we're more likely to do?

maybe is time to move to postgresql , firebird ...

That's one of the reasons why it's called Free Software -- you're absolutely free to move to something else if you like, and we wish you every success with it if you choose to do so.

They have already killed mysql 6.0 "MySQL 6.0 was not developed beyond Alpha status and new releases have not been made for some time, so the manual has been withdrawn as well."

http://dev.mysql.com/doc/refman/6.0/en/index.html

Wrong. We have NOT 'killed' 6.0, but it not going to be the focus of our development for a while, and we won't do any more official 6.0 releases for some time to come. But we HAVE moved it to the back burner, so to speak.

If you really want 6.0, you can get it right here:

https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase

No guarantees right now as to how well it'll build and run on any given day; I think I last built it last Tuesday or Wednesday, and it seemed to do okay, but of course YMMV. That being said, go get the code and knock yourself out.

In the meantime, we're backporting what we think are the best bits of 6.0 to 5.X.

so what is next ?

You'll find some answers to that question here...

http://dev.mysql.com/doc/refman/5.1/en/mysql-next-series-plans.html

And here...

http://dev.mysql.com/doc/refman/5.4/en/

And what's this? The latest release, from less than a week ago:

http://dev.mysql.com/doc/refman/5.4/en/news-5-4-3.html

That's the clone-off date, BTW. Binaries should be available here

http://dev.mysql.com/downloads/mysql/5.4.html

in a few days.

5.x on the death row

I think that's a bit of a stretch. Why don't you see what we say about it on the site?

http://www.mysql.com/about/legal/lifecycle/

NB: We have a choice between (a) honouring the policies on this page and (b) breaking contacts with paying customers.

Can you guess which of these we're more likely to do?

maybe is time to move to postgresql , firebird ...

That's one of the reasons why it's called Free Software -- you're absolutely free to move to something else if you like, and we wish you every success with it if you choose to do so.

They have already killed mysql 6.0 "MySQL 6.0 was not developed beyond Alpha status and new releases have not been made for some time, so the manual has been withdrawn as well."

http://dev.mysql.com/doc/refman/6.0/en/index.html

Wrong. We have NOT 'killed' 6.0, but it not going to be the focus of our development for a while, and we won't do any more official 6.0 releases for some time to come. But we HAVE moved it to the back burner, so to speak.

If you really want 6.0, you can get it right here:

https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase

No guarantees right now as to how well it'll build and run on any given day; I think I last built it last Tuesday or Wednesday, and it seemed to do okay, but of course YMMV. That being said, go get the code and knock yourself out.

In the meantime, we're backporting what we think are the best bits of 6.0 to 5.X.

so what is next ?

You'll find some answers to that question here...

http://dev.mysql.com/doc/refman/5.1/en/mysql-next-series-plans.html

And here...

http://dev.mysql.com/doc/refman/5.4/en/

And what's this? The latest release, from less than a week ago:

http://dev.mysql.com/doc/refman/5.4/en/news-5-4-3.html

That's the clone-off date, BTW. Binaries should be available here

http://dev.mysql.com/downloads/mysql/5.4.html

in a few days.

5.x on the death row

I think that's a bit of a stretch. Why don't you see what we say about it on the site?

http://www.mysql.com/about/legal/lifecycle/

NB: We have a choice between (a) honouring the policies on this page and (b) breaking contacts with paying customers.

Can you guess which of these we're more likely to do?

maybe is time to move to postgresql , firebird ...

That's one of the reasons why it's called Free Software -- you're absolutely free to move to something else if you like, and we wish you every success with it if you choose to do so.

No one is quite sure which is the 'correct' or standard MySQL anymore.

Why? MySQL.com hasn't gone anywhere, and they seem to have plenty of downloads...

http://www.mysql.com/

That'll teach Oracle!

http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html

So what if they had have set the root password for MySQL? Pointless - with local security destroyed it's a trivial operation to reset the password, and it's described directly on the MySQL site here.

MySQL root password reset requires you to have an OS root access. With MySQL having no root password you can access the DB from any local user. There is a difference between having a, let's say, PHP shell on the server and having a root shell. Depending on OS and your skills you can escalate from wwwuser to root, but it's mostly a far from a trivial task.

OK Slashdot, calm down...

I've run databases with no root password as well. It's not as insecure as people are laughing about, and the security problems here stem from sources other than the database. By default, MySQL only allows root access from the local ip of the box. The issue here is that the local security was compromised, hence that protection failed.

So what if they had have set the root password for MySQL? Pointless - with local security destroyed it's a trivial operation to reset the password, and it's described directly on the MySQL site here.

The article doesn't state they used a root db password either, it shows an SQL injection exploit using the "password for its database application". Doesn't mention that the db password was the root db password.

It's still a bad breach obviously, but the nature of the breach is not as the summary describes it.

Cheers,
Ian

Everyone grab a copy of the source, quick!

http://forge.mysql.com/wiki/MySQL_Internals_Guided_Tour#Getting_the_source_tree

All its ancestors rgt values change, so there is only one case where no other nodes are affected: inserting the root in the empty tree.

I'm confused -- are you talking about INSERTs or UPDATEs? The only time when there is one transaction -- an INSERT -- is when you insert the root node. The only time when you can INSERT a node while having to make only one UPDATE to keep the tree ordered is if you INSERT one node on the rightmost side of the tree.

Have a look at this image. '19' is the rgt value of 'Portable Electronics', which is the rightmost node. '20' is the rgt value of 'Electronics', the root node. If you wanted to add one element, 'Gameboys' to the rightmost of the tree, just under the root node, that's one UPDATE:
UPDATE tree SET rgt = 22 WHERE category = 'Electronics';
and one INSERT:
INSERT INTO tree ( category, lft, rgt ) VALUES ( 'Gameboys', 20, 21 );

I realize there may be a distinction between SQL terms and tree manipulation terms, which is why I'm trying to be pedantic. If you are talking about 'updates to the tree' in an abstract sense, as in 'changes to the tree', then yes, there is only one time when there is one update to the tree, when you are INSERTing the root node.

Thanks for a constructive discussion, a actually learned something on /. today :-)

Mark this on the calendar! :)

UPDATE trees SET rgt = rgt + 27, lft = lft + 27 WHERE lft > 107 AND tree_id = 34

I don't know much about how databases write physical data, but I assumed that an update to a single row, regardless of how many columns are updated, counts as a single update.

I don't know what you mean with the tree_id, but you have to update all nodes that follow the inserted one, so on average, half the nodes in the tree or half the rows in that table. According to your link 1

UPDATE nested_category SET rgt = rgt + 2 WHERE rgt > @myLeft; UPDATE nested_category SET lft = lft + 2 WHERE lft > @myLeft;

E.g. if you take the image with the venn diagrams, and insert a new child "ipod" in "mp3", after "flash" these are the changes:

• Electronics rgt = 22
• Portable Electronics rgt = 21
• MP3 rgt = 16
• CD rgt = 18, lft = 17
• 2 Way R. rgt = 20, lft = 19
• Insert iPod, rgt = 14, lft = 15

5 of the 10 nodes are updated, and another 3 are updated again. I don't thinl there is any situation where only one node is affected.

I thought that this representation of the data structure was extraordinarily beautiful, in the sense of elegant. Perhaps you just don't like tree data structures, aesthetically?

For anyone wondering, parent is talking about a preorder tree traversal algorithm:
Link 1
Link 2

And parent it right. I was doing an adjacency list in MySQL for a while, because I thought that preorder trees were just a little too complicated, but they are *way* easier and more intuitive.

Inefficient?

See: http://dev.mysql.com/doc/refman/5.1/en/replication-features-auto-increment.html

Quote: Prior to MySQL 5.1.12, when a stored routine or trigger caused an INSERT into an AUTO_INCREMENT column, the generated AUTO_INCREMENT value was not written into the binary log, so a different value could in some cases be inserted on the slave.

Using replication written by people who regularly release stuff of such "quality", is being inefficient - you'll eventually be wasting a lot of time.

A prev company I worked for stupidly used MySQL for a lot of stuff and I'd say it has cost them quite a fair bit. They've had lost data, corrupted data and server crashes (not hardware related).

that, and the fact that four years later from the original bug report, stored procedures still can't even find out what caused a thrown exception, with no indication that they even give a damn about it. Working with stored procs under MySQL is a frigging joke.

No, the replication and hot standby patches were not considered of high enough quality to be a part of 8.4. They will be a high priority during development of 8.5.

PostgreSQL would never, ever ship something which has a WTF-list as long as MySQL's replication does: http://dev.mysql.com/doc/refman/5.0/en/replication-features.html

Licence pedantry is why, IMHO.

Think about it as analgous to BSD vs Linux. They both do roughly the same thing in roughly the same way. One has been around longer, is more mature, and is in many ways better than the other. The other simply has the limelight and, for many people, a preferable licence, which is why mysql is/was/tends-to-be bundled in with distros.

People get their dangfangled lunix thing, mysql comes with it and they run with it without knowing any better. So they are either innocently unaware that something more suited to their needs could be out there, or they could be actively ignorant e.g. "it's not GPL so it's not free, I have to use GPL to maintain my liberty!!!" and other RMS vomit. People who actually understand what each system is capable of and make an educated choice either way are a rare breed.

My current gripe with MySQL goes with having company staff using a bugtracker tool that suffers the same "copying to tmp table" lockup problem mentioned in this thread, which has been open since 2005. The MySQL devs response can be summed us as "meh... the fix is in 6 alpha, so kiss my(sql) ass". Well, sorry chaps, but we don't run production systems on alpha software for a reason. If the fix we've been waiting nearly four years for isn't in apt, then I suggest you get it there.

My company does not want to migrate to another DBMS, and they don't particularly want to fix the queries that are triggering this behaviour from mysql (nor should they have to!), so I've spent the last few months tweaking and retweaking mysql's configuration with marginal gain. Now the company has dished out for a brand spanking new box with a trillion cores and a bucket of ram, despite me pointing out that MySQL likely wouldn't be able to effectively use all the resources (see links above for sustained throughput and multi-thread I/O graphs). So because the MySQL devs refuse to fix their fuck up in a timely manner, I have to sit here and get irritated while my employer makes Dilbertonian decisions. Thanks, MySQL!

Sure, but Mysql doesn't have that. Here's a really old worklog for pluggable authentication. There's a blog on it also.

Sure, but Mysql doesn't have that. Here's a really old worklog for pluggable authentication. There's a blog on it also.

It is already being done.

Many of us MySQL users see your Postgres question the same way: why use Postgres?

Because MyISAM, which is what most MySQL users use, is not fucking ACID compliant.

Take a look at the potential problems. Take a look at recommended use cases: "Tables which contain read-only data, throw-away data, data which can be quickly re-generated." Are you bloody kidding me!?

I can't believe my eyes when I read questions (or posts) such as the above. Because it betrays your huge ignorance. Every man and his dog has heard of MySQL and is probably using it, true. But it's also true that most of them have no bloody idea of what ACID is or why it's desirable, or that MySQL with its MyISAM tables goes completely happy-go-lucky on the whole concept. These are the same people who probably don't bother using foreign keys, or have never even heard of transactions, or can't think why they'd need them.

Sure, MySQL offers InnoDB, which is supposed to rectify those issues. But how does it go about it, may I ask? Why, take a looksy. It's an entire bloody SECTION of the manual, which goes to great lengths to explain all kinds of issues and exceptions to the rules and whatnot. Summary: "It locks rows like this, except if it's a full moon then you have to blink your left eye every five seconds, and if you're doing a particular SELECT you need to stand on one leg, except on Fridays when it's the right leg."

Now compare with the Postgres manual page describing their ACID implementation. It's a couple of pages, keeping things clear and simple, so that anybody can understand them.

Not to forget that if you want InnoDB you give up full text search capabilities. And you ask why we should use Postgres? Really?

MySQL has lowered the bar for complexity of use. But in doing so it has facilitated DB access to a whole bunch of people who don't have any idea what they're doing, or don't really care about data integrity. It's fast and it works most of the time so it's alright, yes? Yes, granted, nobody will care much if your personal blog goes tits up because of MySQL. But I expect people will care if a database in which data actually counts for something has problems. And in such cases I expect people will want a real database.

In the OSS world it's called "release early, release often" (example)

But hey, one mans 'terrorism' is another mans 'shock and awe'.

Sounds like you haven't been following MySQL AB very closely. Their interpretation of the license was that any time you paired a MySQL database with an application, you needed a MySQL commercial license. Only if the application supported but was independent of MySQL would you not need to follow the terms of the license.

MySQL even tried to reinforce the idea by purchasing all the third party drivers and changing the licenses to GPL instead of LGPL or otherwise.

While MySQL's licensing info has changed over the years (interestingly not archived by the WayBack Machine...) even their current page on licensing is designed to steer users toward purchasing a commercial license:

Q3: As a commercial OEM, ISV or VAR, when should I purchase a commercial license for MySQL software?

A: OEMs, ISVs and VARs that want the benefits of embedding commercial binaries of MySQL software in their commercial applications but do not want to be subject to the GPL and do not want to release the source code for their proprietary applications should purchase a commercial license from Sun. Purchasing a commercial license means that the GPL does not apply, and a commercial license includes the assurances that distributors typically find in commercial distribution agreements.

For quite a few legal departments I've worked with, "the GPL does not apply" is magic words to their ears. They will instruct the business to grab the commercial license to get around the restrictions. In addition, there is the MySQL libraries issue I referred to above:

Q4: What is Sun's dual license model for MySQL software?

A: Sun makes its MySQL database server and MySQL Client Libraries available under both the GPL and a commercial license. As a result, developers who use or distribute open source applications under the GPL can use the GPL-licensed MySQL software, and OEMs, ISVs and VARs that do not want to combine or distribute the MySQL software with their own commercial software under a GPL license can purchase a commercial license.

The MySQL forking company is going to have to undo all of the anti-GPL ideas they've been riding, and convince companies that they don't need a commercial license. (Since it's not in the forking company's power to provide one.)

If the copyright holder is allowed to revoke the license, they could close up any project that they own copyright to without allowing any forks. It would mean a loss of MySQL and OpenOffice.org as free software forever.

This is taken care of by section 6 of the GPL v2 (though it appears as section 7 in the MySQL documentation for version 5.0 at least.

• Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

If I give you a copy of MySQL that I download today, you automatically get a license to modify and distribute from the copyright holder. Any copies you distribute will likewise have a perpetual license as long as you and the recipient obey the requirements of the GPL V2.

That's not something Sun or Oracle can take away from you. They can stop releasing new versions under the GPL as they own the code (anyone submitting patches must agree to the Sun Contributer Agreement). They cannot, however, unGPL the code that has already been released.

It's GPL not LGPL. Oracle really can't use any of that open source stuff unless the product they release is also open source.

For example I've just dealt with a Java app that connects to MySQL.
The MySQL Java connector (Connector/J 5.1) is part of our program. It isn't LGPL licensed, it's GPL. So it requires a license to use in a commercial closed source program.
http://www.mysql.com/products/connector-j

Note the link to buy a commercial license on that page.

Oracle buying Sun -- the question is not whether this is a surprise, but why it didn't happen long before now. And, importantly, if the FTC will block it on the grounds that it would create too close to a monopoly in the DB market.

How? In terms of sales, MySQL is a rounding error, and won't budge Oracle from their mid-to-high-40's position. In terms of developer usage, it MySQL + Oracle is just over 50%. MySQL + Oracle isn't anything like a monopoly.

The only way to get an instant DB monopoly by merger would be if Oracle, IBM, and Microsoft underwent a three-way merger. Which is somewhat unlikely.

It's been about 3 years since I worked with Oracle (10g RAC), but Toad and SQL* are really terrible tools. Now at least they have the MySql Workbench

And MySql TCO calculator will probably vanish very rapidly, since Oracle cost is compared directly with MySql...

It's been about 3 years since I worked with Oracle (10g RAC), but Toad and SQL* are really terrible tools. Now at least they have the MySql Workbench

And MySql TCO calculator will probably vanish very rapidly, since Oracle cost is compared directly with MySql...

mysql> create table foo(bar varbinary(10));
mysql> insert into foo (bar) values ('abc');
mysql> select * from foo where bar = 'abc';
+------+
| bar |
+------+
| abc |
+------+
1 row in set (0.00 sec)

mysql> select * from foo where bar = 'aBC';
Empty set (0.00 sec)

the varchar type are case insensitive. varbinary types do what you are expecting.
http://dev.mysql.com/doc/refman/5.1/en/binary-varbinary.html

If I wasn't so lazy and logged in - I would give you a -5 Troll - This is a great move for their database market - just look at the graph: http://www.mysql.com/why-mysql/marketshare/ That would give them OVER 50% of the market share! If their current for profit market share of 23% is worth a market cap of $95B, than paying a little measly $8B for that other 29% seems pretty braindead. Then just turn on the salesforce guys...

Well, how about completely ignoring the "REFERENCES othertable(othercolumn)" syntax for foreign key constraints without as much as a warning in even the strictest mode, leaving you without referential integrity without any way of knowing?

This is new to me. I've used foreign keys and seen it complain when the constraints aren't met. I know this happens in MyISAM though (because there are no foreign keys). I'd like to see an example of where InnoDB doesn't respect the constraints

and those other 3 things you said.

1. of course it takes some tweaking of a database to get stuff working the way you want it. granted tweaking for ACID compliance isn't ideal
2. I'm not going to bother responding to each of your points as you know damn well that you were quoting the MySQL 4.1 manual and at least 1, if not more, of your points are invalid now in MySQL 5.0
3. InnoDB defaults to off too. If you're going to enable InnoDB because you're looking for an ACID RDBMS, then you should also configure your database server to properly utilize InnoDB.

Stick to apples-apples comparisons. None of those companies are using MySQL as a relational database (say, doing their accounting in it or trusting their business on it)

Google is using it to power their adwords. How is that not "their business"? besides that, there are plenty of companies out there that run their "business" on mysql. you know it, i know it, every postgres, oracle, mssql dba knows it. here's some more info...

Good DBAs aren't cheap and MySQL is needs more developer time to work around its limitations than any other database (in my humble opinions).

I like Oracle a lot, but I'm not sure I buy your argument that there is a cost savings realized by using it.

Here is a TCO analysis that we must obviously take with several heaping grains of salt considering its source, but it puts the numbers to my thoughts on the subject.

Oracle RAC is monumentously expensive, so if you can get away with MySQL cluster, I think it's advisable in many circumstances.

The TCO comparison from MySQL doesn't even address DBA time, which as you thoughtfully pointed out, is not cheap. But have you ever been to an Oracle shop that lacked a small army of expensive Oracle DBAs?

For what it's worth, most of my clients (i.e. the ones who can afford me) use Oracle, and feel compelled to point out that I've sure seen my share of hacks needed to make Oracle behave, too. ;)

Pgpool can't even add a node to a degraded cluster without client lockout. This is totally unacceptable.

Regarding mysql, you are right, adding a data node requires a restart, but mysql cluster restarts are "rolling restarts". Clients are NOT locked out during a rolling restart. BTW, even the rolling restart can be avoided if the initial cluster in configured with extra, unused node groups added to the config file for future expansion.

You can find the instructions for the online adding data nodes to a MySQL cluster here.

No DML statements are blocked during the above operation.

2. "Pgpool". If I have to lock out all clients just to add a node to the cluster, then it is not a high-availability solution.

As opposed to a database where modifying a table (add/remove an index, column) results in the entire table being rewritten on disk under a full table lock ? And you actually argue that database for high availability ?

As opposed to: The cluster can not be expanded dynamically, and has to be restarted to introduce new nodes. This limits availability in a dynamic setting. (source). Or directly from the horse's mouth: Adding and dropping of data nodes. Online adding or dropping of data nodes is not currently possible. In such cases, the entire cluster must be restarted. ?

i asked you a valid question, how does innodb not maintain referential integrity? you bring up myisam. i didn't mention myisam. i know myisam isn't ACID. i asked you how innodb isn't. and as for error reporting, http://dev.mysql.com/doc/refman/5.1/en/error-handling.html. so again, how does innodb not take referential integrity and error reporting seriously?

Well, how about completely ignoring the "REFERENCES othertable(othercolumn)" syntax for foreign key constraints without as much as a warning in even the strictest mode, leaving you without referential integrity without any way of knowing?

Or from the manual: "By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes there is a chance that the last statements of the binary log are lost. To prevent this, you can make the binary log be synchronized to disk after every Nth binary log write, with the sync_binlog global variable (1 being the safest value, but also the slowest)."

So InnoDB still defaults to non-ACID behaviour, but it doesn't stop there yet:

More from the manual: Even with [sync_binlog] set to 1, there is still the chance of an inconsistency between the tables content and the binary log content in case of crash. [...] This problem can be solved with the --innodb-safe-binlog option (available starting from MySQL 4.1.3), which adds consistency between the content of InnoDB tables and the binary log. For this option to really bring safety to you, the MySQL server should also be configured to synchronize to disk, at every transaction, the binary log (sync_binlog=1) and (which is true by default) the InnoDB logs.

Another option if you want ACID. Oh wait, there's a 3rd, since binlog defaults to off so you need to enable that too. Three options have to be changed from their defaults to get durability after each and every single commit (when we're talking databases, that's kind of what I expect. If you don't, that's fine, but we're not talking about the same thing then)

, are you referring to companies like google, yahoo, or alcatel-lucent? need i really go on?

Stick to apples-apples comparisons. None of those companies are using MySQL as a relational database (say, doing their accounting in it or trusting their business on it), sure Google uses it as a memory-only non-transactional clustered datastore with an SQL query interface, after having put in a lot of patches to make that work, but so what? Yes, use it for that, sure use MyISAM for your blog, but when we're talking about a proper relational database where "commit" means the data is stored, where a foreign key means a foreign key and where you would run your core business on it then stick to those cases where it's actually used as such. A better example for that is Skype, which runs its entire operations from buddylists to billing on Postgresql.

you might not have been degrading (you kind of are with your last statement), but plenty of postgres, mssql, and oracle users are. i hate going into ##sql on freenode, asking a question about SQL 92 joins and I get kicked because I said I'm using MySQL. WTF does mysql have anything to do with SQL92 syntax?

and here's where you start to get slightly condescending...

When you clean up enough messes left by people who have no business touching a database, it gets fustrating. Especially when things like this are said:

and

Or are those examples only good for Fortune 10(tm) enterprises and not some piddly organization like yours.

i asked you a valid question, how does innodb not maintain referential integrity? you bring up myisam. i didn't mention myisam. i know myisam isn't ACID. i asked you how innodb isn't. and as for error reporting, http://dev.mysql.com/doc/refman/5.1/en/error-handling.html. so again, how does innodb not take referential integrity and error reporting seriously?

by the way, when you say

piddly organizations like yours

, are you referring to companies like google, yahoo, or alcatel-lucent? need i really go on?

so even though you say you aren't being condescending, you still maintained to act like an elitist pretentious ass. congratulations. thats exactly the type of attitude us mysql users are fed up with from you non-mysql users.

and yes, i agree with you that mysql's not null default data is complete bullshit, but that was never part of your original argument