Slashdot Mirror

I think this is a huge misconception, and completely backwards. MySQL allows you to change storage engines, but the behavior at the semantic level changes. That's the antithesis of modularity: the semantic behavior should remain constant, while the performance changes. If you change both, that's not modularity, that's a new configuration that breaks client applications.

In theory, I see your point. It's not truly modular. In practice, it's handy. MyISAM and InnoDB tables work quite well together.

MySQL is configureware, like PHP. Everything you get is a trade. Want full text indexes (MyISAM)? You have to give up transactions (InnoDB). But the marketing material always just says "Yup, we have full text indexes (MyISAM), SQL compliance (strict mode=on), transactions (InnoDB), large number of apps (strict mode=off)". Of course many of the features are mutually exclusive. When postgresql says it has a feature, it's really there.

Right. And that's a good thing about Postgresql. Now tell me, what do you do in Postgresql when you just want a fast table with no transactional overhead (MyISAM)? Or memory only data? Access to the minimal features can be just as valuable as always having everything available. I could care less which company is more honest in their marketing. I guess the MySQL folks are much better marketers, at the cost of a little transparency.

Seems like the memory engine and NDB are the same thing: http://dev.mysql.com/doc/refman/5.0/en/mysql-clust er-overview.html. That means that your "cluster" is not much of a database, and is totally unacceptable for many applications that require a database. Power off == no more data.

No. The memory (or "heap" engine) is just that - a simple in-memory engine: http://dev.mysql.com/doc/refman/5.1/en/memory-stor age-engine.html NDB is the storage engine for MySQL Cluster, and it most certainly is acceptable for applications that need a high-availability clustered solution. The details are way beyond the scope of this post, but it's certainly no joke and is in use in some very high-demand applications (try high-traffic telecommunication apps).

Now compare with PostgreSQL. PostgreSQL has one "storage-engine", but there are many access methods to that storage engine. There's Btree, GiST, and GIN. On top of the access methods, there are also a lot of plans. There's sequential scan, index scan (good for lookups or some sorting needs), bitmap index scan (good for AND/OR with other bitmap index scans, and always orders the I/O in file order), hash join, hash aggregate, merge join, nested loop, group aggregate, etc.

That's nice. Good features. There are also lots of ways to optimize searches in MySQL. BTW, I like Postgresql. Never said I don't.

Look at all those algorithms for accessing the single storage mechanism. It's amazing. MySQL doesn't have all those, and even if it did have the algorithms, it couldn't use them. How would MySQL know when to use a hash join and when to use a merge join? PostgreSQL collects statistics, calculates expected costs, and chooses the best plan based on the given query (called a cost-based planner). MySQL uses a rule-based planner (does it have an index? ok, let's use it then). To PostgreSQL, these two queries are different: (1) SELECT * FROM parents WHERE number_of_children=2; (2) SELECT * FROM parents WHERE number_of_children=20; The stats collector would know that #1 will match many more records than #2. It will probably choose a sequential scan for #1, since it needs to read every page anyway. It will probably choose an index scan for #2. Now, if that's in a subselect, postgresql will know that #1 will return a lot of records, and maybe choose a different

I think this is a huge misconception, and completely backwards. MySQL allows you to change storage engines, but the behavior at the semantic level changes. That's the antithesis of modularity: the semantic behavior should remain constant, while the performance changes. If you change both, that's not modularity, that's a new configuration that breaks client applications.

In theory, I see your point. It's not truly modular. In practice, it's handy. MyISAM and InnoDB tables work quite well together.

MySQL is configureware, like PHP. Everything you get is a trade. Want full text indexes (MyISAM)? You have to give up transactions (InnoDB). But the marketing material always just says "Yup, we have full text indexes (MyISAM), SQL compliance (strict mode=on), transactions (InnoDB), large number of apps (strict mode=off)". Of course many of the features are mutually exclusive. When postgresql says it has a feature, it's really there.

Right. And that's a good thing about Postgresql. Now tell me, what do you do in Postgresql when you just want a fast table with no transactional overhead (MyISAM)? Or memory only data? Access to the minimal features can be just as valuable as always having everything available. I could care less which company is more honest in their marketing. I guess the MySQL folks are much better marketers, at the cost of a little transparency.

Seems like the memory engine and NDB are the same thing: http://dev.mysql.com/doc/refman/5.0/en/mysql-clust er-overview.html. That means that your "cluster" is not much of a database, and is totally unacceptable for many applications that require a database. Power off == no more data.

No. The memory (or "heap" engine) is just that - a simple in-memory engine: http://dev.mysql.com/doc/refman/5.1/en/memory-stor age-engine.html NDB is the storage engine for MySQL Cluster, and it most certainly is acceptable for applications that need a high-availability clustered solution. The details are way beyond the scope of this post, but it's certainly no joke and is in use in some very high-demand applications (try high-traffic telecommunication apps).

Now compare with PostgreSQL. PostgreSQL has one "storage-engine", but there are many access methods to that storage engine. There's Btree, GiST, and GIN. On top of the access methods, there are also a lot of plans. There's sequential scan, index scan (good for lookups or some sorting needs), bitmap index scan (good for AND/OR with other bitmap index scans, and always orders the I/O in file order), hash join, hash aggregate, merge join, nested loop, group aggregate, etc.

That's nice. Good features. There are also lots of ways to optimize searches in MySQL. BTW, I like Postgresql. Never said I don't.

Look at all those algorithms for accessing the single storage mechanism. It's amazing. MySQL doesn't have all those, and even if it did have the algorithms, it couldn't use them. How would MySQL know when to use a hash join and when to use a merge join? PostgreSQL collects statistics, calculates expected costs, and chooses the best plan based on the given query (called a cost-based planner). MySQL uses a rule-based planner (does it have an index? ok, let's use it then). To PostgreSQL, these two queries are different: (1) SELECT * FROM parents WHERE number_of_children=2; (2) SELECT * FROM parents WHERE number_of_children=20; The stats collector would know that #1 will match many more records than #2. It will probably choose a sequential scan for #1, since it needs to read every page anyway. It will probably choose an index scan for #2. Now, if that's in a subselect, postgresql will know that #1 will return a lot of records, and maybe choose a different

MySQL is modular [ from grandparent post ]
The point IS pick'n'mix as you put it. [ from parent ]

I think this is a huge misconception, and completely backwards. MySQL allows you to change storage engines, but the behavior at the semantic level changes. That's the antithesis of modularity: the semantic behavior should remain constant, while the performance changes. If you change both, that's not modularity, that's a new configuration that breaks client applications.

MySQL is configureware, like PHP. Everything you get is a trade. Want full text indexes (MyISAM)? You have to give up transactions (InnoDB). But the marketing material always just says "Yup, we have full text indexes (MyISAM), SQL compliance (strict mode=on), transactions (InnoDB), large number of apps (strict mode=off)". Of course many of the features are mutually exclusive. When postgresql says it has a feature, it's really there.

Just need some in-memory lookups? Memory table engine. Clustered data? NDB.

Seems like the memory engine and NDB are the same thing: http://dev.mysql.com/doc/refman/5.0/en/mysql-clust er-overview.html. That means that your "cluster" is not much of a database, and is totally unacceptable for many applications that require a database. Power off == no more data.

Now compare with PostgreSQL. PostgreSQL has one "storage-engine", but there are many access methods to that storage engine. There's Btree, GiST, and GIN. On top of the access methods, there are also a lot of plans. There's sequential scan, index scan (good for lookups or some sorting needs), bitmap index scan (good for AND/OR with other bitmap index scans, and always orders the I/O in file order), hash join, hash aggregate, merge join, nested loop, group aggregate, etc.

Look at all those algorithms for accessing the single storage mechanism. It's amazing. MySQL doesn't have all those, and even if it did have the algorithms, it couldn't use them. How would MySQL know when to use a hash join and when to use a merge join? PostgreSQL collects statistics, calculates expected costs, and chooses the best plan based on the given query (called a cost-based planner). MySQL uses a rule-based planner (does it have an index? ok, let's use it then). To PostgreSQL, these two queries are different:

  (1) SELECT * FROM parents WHERE number_of_children=2;
  (2) SELECT * FROM parents WHERE number_of_children=20;

The stats collector would know that #1 will match many more records than #2. It will probably choose a sequential scan for #1, since it needs to read every page anyway. It will probably choose an index scan for #2. Now, if that's in a subselect, postgresql will know that #1 will return a lot of records, and maybe choose a different join algorithm than if it were #2. Again, PostgreSQL chooses these plans for you based on cost -- no special configuration required.

If you want modular, it's being able to replace a full text GiST index with a full text GIN index and the application never knows the difference except performance. And by the way, the DDL in postgresql is transactional, so you don't even have to restart the application even if you do some major restructuring of the table (like replacing a table with an updatable view).

Yeah, the Genome Project, Google, Berkley, various Defense Departments, NASA, the UN, Los Alamos, MIT, BBC, Apple, Adobe, Wikipedia, etc.

Did I mention Slashdot uses MySQL?

Clearly, anyone who uses MySQL clearly must be an idiot.

http://www.mysql.com/customers/

Someone please mod this guy for trolling.

I use SQL server everyday. I have to write custom functions in MS SQL Server to pump into Crystal Reports, and I loathe it.

MS SQL Server sucks for the following three reasons, among many others:

1 - MySQL is more ANSI SQL compliant and MS has no respect for standards.
2 - MySQL can run on multiple platforms and doesn't require a GUI. When you have to shell out tens of thousands of dollars for a server (if not hundreds of thousands of dollars) it is important to note that MS SQL will only run on Windows, on an x86 architecture and is going to cost you considerably more money and have worse performance. A cheap Linux server on the architecture of your choice will destroy that Windows server in performance and cost less money.
3 - Even when running on the same hardware and OS, MySQL destroys MSSQL in performance. I mean, kicks MSSQL's teeth in.

http://www.mysql.com/why-mysql/benchmarks/eweek.ht ml

And, they are two separate products:

http://en.wikipedia.org/wiki/Windows_Messenger
http://en.wikipedia.org/wiki/Microsoft_Messenger

Google could have told you that. Instead you call bullshit on me?

Poor form. Next time do some research and know what you're talking about.

You can set SQL modes, such as STRICT_ALL_TABLES, that will cause MySQL to reject invalid data instead of truncating it. There is documentation about the various SQL modes.

Because this is a GPL protocol, any product which uses it to connect to a MySQL server, or to emulate a MySQL server, or to interpose between any client and server which uses the protocol, or for any similar purpose, is also bound by the GPL. Therefore if you use this description to write a program, you must release your program as GPL.

MySQL 5.2 has been renamed 6.0. The only difference between 6.0 and 5.1 is the Falcon storage engine. 6.0 is in Alpha. You can download it at: http://dev.mysql.com/downloads/mysql/6.0.html

There is such a thing as programming creative flow. For instance, say you're coming up with a prototype for a new site. You just want to get in there, come up with a basic database that fits your needs, come up with a data API, and then write some dynamically generated HTML. If you've done it a thousand times before, it's just going through the motions and getting the code written. And if you're in this situation and you can't quite remember how to query for all rows within a specific month -- ya, it does slow you down a bit.

I completely disagree with the spam article's premise that it'd be faster for me to go find a card laying somewhere on my desk, or that my creative flow wouldn't be broken by STANDING UP AND GOING TO LOOK AT A WALL POSTER, rather than going to the absolutely excellent MySQL documentation site, where I can actually cut and paste from examples. There's hardly ever a question about MySQL syntax or SQL functionality I can't get from the MySQL documentation. The only places where the MySQL developer guide lacks is in performance guidelines, but I don't expect that the spammed product does a better job on a laminated card.

It has a function list built-in sorted by function type.

Screenshot (lower right):
http://www.mysql.com/products/tools/query-browser/ qb-win-03-diff.png

Then if you double-click the function it brings up a popup telling you the full usage + description.

Where can I download MySQL 5.2? http://dev.mysql.com/

from all those cash infusions* from microsoft, Baystar, and Royal Bank of Canada.
I expect the 60 million got invested into the pump-n-dump also, so there should be
plenty to stick in MySQL's G-string.

[*]
http://uk.builder.com/0,39026540,39338281,00.htm
http://www.mysql.com/news-and-events/news/article_ 948.html
http://slashdot.org/article.pl?sid=03/05/19/105522 3
http://news.zdnet.com/2100-3513_22-5057033.html

You should look at mysql cluster. I'm yet to use it, but for a write heavy and high-availability SQL DB it's a pretty good option.

http://dev.mysql.com/doc/refman/5.0/en/mysql-clust er-overview.html

Cheers,
Tim

Pretty decent testimonials for the support as well.

You can go with a slower speed and higher data integrity by switching from MyISAM to InnoDB tables. The choice is there, so I would use the term "always sacrifice".

They did that in 5.0 with strict mode.

http://dev.mysql.com/doc/refman/5.0/en/server-sql- mode.html

The links you provide are to a very old version of Mysql (3.2xxx), which was current around 6 years ago.

The newer Mysql version, depending on which storage engine you use, support foreign keys: Version 5.1

You really shouldn't link to a page about MySQL's partitioning support without linking the following:

http://dev.mysql.com/doc/refman/5.1/en/partitionin g-limitations.html

"Without partitioning"? What are you trying to say, that db2/Oracle doesn't have such a basic feature?

Seriously, have you ever found yourself away from an Internet connection lately? I actually have a couple pocket references from years ago, but once the PHP manual and its user submitted comments hit the web, all manuals have adopted this technique, and we are all better off. Pocket references are soooooo 2002.

http://dev.mysql.com/doc/

RTFMS

'nuff said.

From the MySQL website: "The official way to pronounce "MySQL" is "My Ess Que Ell" (not "my sequel"), but we don't mind if you pronounce it as "my sequel" or in some other localized way."

Personally, I think the breakthrough for managing data warehousing volumes of data with real-time response is going to come from NitroSecurity's NitroEDB. I saw a demo they gave running on a single commodity laptop which delivered query responses thousands of times faster than Oracle, on a data set with billions of records. They're working with MySQL creating an interface to use NitroEDB as a storage engine as well.

It not only can, it does.

How do you figure that? Are you aware of such companies as Trolltech (who owns the copyright to the QT libraries and licenses these copyrights differently according to the situation) or MySQL AB who does the same with many (most/all?) of their products? There are no restrictions placed by the GPL on these companies and how they see fit to distribute their software. The GPL does, however, place restrictions on whoever decides to redistribute this software under the terms of the GPL

No, MySQL AB did not stop providing binaries. The Debian folks were building their MySQL packages by themselves all the time before, MySQL AB has never provided DEBs for download. And as you can read on the MySQL 5.0 Download pages:

In contrast to the MySQL Enterprise Server, which receives both monthly rapid updates and quarterly service pack releases, there is no specific schedule for when a new version of the MySQL Community Server is released. While every bug fix that has been applied to the Enterprise Server will also be available in the subsequent Community Server release, there will be source-only releases in between full (source and binary) Community builds. So while the latest published community sources will always be available from the Source Downloads Section, the binaries listed on this page may be from a previous release. In any case, full binaries for all our supported operating systems are and will remain conveniently available from this page.

No, MySQL AB did not stop providing binaries. The Debian folks were building their MySQL packages by themselves all the time before, MySQL AB has never provided DEBs for download. And as you can read on the MySQL 5.0 Download pages:

In contrast to the MySQL Enterprise Server, which receives both monthly rapid updates and quarterly service pack releases, there is no specific schedule for when a new version of the MySQL Community Server is released. While every bug fix that has been applied to the Enterprise Server will also be available in the subsequent Community Server release, there will be source-only releases in between full (source and binary) Community builds. So while the latest published community sources will always be available from the Source Downloads Section, the binaries listed on this page may be from a previous release. In any case, full binaries for all our supported operating systems are and will remain conveniently available from this page.

PostgreSQL has done far more with far less capital.

Since you probably won't believe me, I invite you to compare the features of each. Visiting each project's web site is a good place to start. Once you see how much further ahead PostgreSQL is technologically than MySQL, consider how they managed to accomplish that with relatively little capital.

One of my criterias for "software healthiness" is how much the community is involved in the development and management of the source code. It is interesting to see that the source code for MySQL is stored in a BitKeeper repository instead of something more community-friendly like CVS or Subversion. A real turn-off for me, at least.

Sorry to hear that you don't like MySQL, but great to see that you nevertheless take time to read /. postings about us and to post your own. Let us know what "warts" you see in our product and help us improve it. Then perhaps one day you will find that it serves your needs.

I don't like that MySQL does not keep my data safely and securely out of the box. Some examples:

• I need to flip a whole set of knobs to make MySQL return failure on invalid data. Apparently TRADITIONAL, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_VALUE_ON_ZERO, NO_ENGINE_SUBSTITUTION, NO_UNSIGNED_SUBTRACTION, NO_ZERO_DATE, NO_ZERO_IN_DATE, ONLY_FULL_GROUP_BY, and STRICT_ALL_TABLES. No other RDBMS even has these knobs, much less has the defaults wrong.
• There's no way (that I can find) to completely turn off non-transactional tables. As I understand it, if I forget to tell it when creating a table to make it transactional, it's silently not. If a transaction involves even a single non-transactional table, the whole thing is non-transactional. This makes me nervous.
• I don't know if it does an fdatasync() at the right times out of the box on all table types. I need ACID, not doubt.
• When users have no password set, anyone can connect without a password. Contrast to PostgreSQL: no one connects without authentication unless you explicitly say so in the configuration file. But it's unobtrusive because local users can authenticate via Unix domain sockets / SO_PASSCRED.

I can't take MySQL seriously until this changes. I understand that you have backward compatibility concerns, but that's life - you pay a price for the poor decisions you've made in the past. You might have to go through a long deprecation period before you can get rid of these knobs. At the very least, don't have them flipped this way unless I start mysqld with the --treat-my-data-as-garbage command-line option.

If you fix this fundamental problem, I'll be impressed. I may not use your product, but I will stop laughing at it.

Well, instead of trolling for Postgres, let's mosey on over to the MySQL website and see if we can figure out why someone might want to pay, hrm? Ahh yes, here we go, MySQL Enterprise. Mmm. Let's click that. Iiiinteresting. Says here you get 24x7 web and phone support plus 30 minute emergency response time. Eat that, pgsql-bugs. You also get consultative support from people who spend all day tuning MySQL installations for max performance and reliability. I can't even find the Postgres analogue of that to make fun of. Lots of other goodies too numerous to mention that might be worth paying for.

If you're tossing Wankr 2.1 together in your bedroom then MySQL free, pgsql, or even sqlite is more than enough to meet your needs. If you run a large business that relies on MySQL to actually make some $$, then purchasing support is a rational choice. Especially since TCO is still about an order of magnitude less than competition.

Well, instead of trolling for Postgres, let's mosey on over to the MySQL website and see if we can figure out why someone might want to pay, hrm? Ahh yes, here we go, MySQL Enterprise. Mmm. Let's click that. Iiiinteresting. Says here you get 24x7 web and phone support plus 30 minute emergency response time. Eat that, pgsql-bugs. You also get consultative support from people who spend all day tuning MySQL installations for max performance and reliability. I can't even find the Postgres analogue of that to make fun of. Lots of other goodies too numerous to mention that might be worth paying for.

If you're tossing Wankr 2.1 together in your bedroom then MySQL free, pgsql, or even sqlite is more than enough to meet your needs. If you run a large business that relies on MySQL to actually make some $$, then purchasing support is a rational choice. Especially since TCO is still about an order of magnitude less than competition.

Well, instead of trolling for Postgres, let's mosey on over to the MySQL website and see if we can figure out why someone might want to pay, hrm? Ahh yes, here we go, MySQL Enterprise. Mmm. Let's click that. Iiiinteresting. Says here you get 24x7 web and phone support plus 30 minute emergency response time. Eat that, pgsql-bugs. You also get consultative support from people who spend all day tuning MySQL installations for max performance and reliability. I can't even find the Postgres analogue of that to make fun of. Lots of other goodies too numerous to mention that might be worth paying for.

If you're tossing Wankr 2.1 together in your bedroom then MySQL free, pgsql, or even sqlite is more than enough to meet your needs. If you run a large business that relies on MySQL to actually make some $$, then purchasing support is a rational choice. Especially since TCO is still about an order of magnitude less than competition.

Well, instead of trolling for Postgres, let's mosey on over to the MySQL website and see if we can figure out why someone might want to pay, hrm? Ahh yes, here we go, MySQL Enterprise. Mmm. Let's click that. Iiiinteresting. Says here you get 24x7 web and phone support plus 30 minute emergency response time. Eat that, pgsql-bugs. You also get consultative support from people who spend all day tuning MySQL installations for max performance and reliability. I can't even find the Postgres analogue of that to make fun of. Lots of other goodies too numerous to mention that might be worth paying for.

If you're tossing Wankr 2.1 together in your bedroom then MySQL free, pgsql, or even sqlite is more than enough to meet your needs. If you run a large business that relies on MySQL to actually make some $$, then purchasing support is a rational choice. Especially since TCO is still about an order of magnitude less than competition.

MySQL's mascot is a dolphin.

And it seems like this guy worked on databases.

Postgres is fully ACID compliant

As is MySQL.

has mature support for just about everything

It lacks anlaytic functions.

Adding to that is the fact that PHP has never had a sane database interface, even though it's freakin' designed to interface with databases! Code like: mysql_query("SELECT * FROM foo WHERE bar='". sqlClean($bar). "'") is just plain hard to read and is just plain prone to error. Give me something like query("SELECT * FROM foo WHERE bar=?", $bar) any day. The compiler should do the heavy lifting for me -- as a programmer I should worry about solving problems. Navigating through spaghetti like "'".clean($var)."'" is not something I ever want to do.

Thanks for saying that. It is one of the things that I hate the most about PHP (manually quoting data for the database). This is from http://dev.mysql.com/tech-resources/articles/4.1/p repared-statements.html. stating how you have to use a different (and only included with PHP5) interface to use prepared statements and bind parameters.

Another API that has prepared statement support is PHP. PHP 5 has a new MySQL interface called "mysqli". You can read more about the mysqli extension in the mysqli section of the PHP Manual. The API provided by the mysqli extension is also nearly a one-for-one match with the C API, so the documentation for the C API may also be useful in learning about the PHP API.

Those of you that are Perl or Java users have had prepared statements for quite a long time. However, those were client-side prepared statements. The client-side prepared statements provide the same security benefit, but none of the performance increases. Don't worry though, MySQL Connector/J has support for server-side prepared statements in the new 3.1 release. Perl's DBD::mysql driver will have support in the next release of the 2.9 tree. The best part is that your code is already written to use them, so all you have to do to take advantage of the new feature is to upgrade the driver behind the scenes.

It's not like they (PHP devs) had nothing to learn from, I believe ODBC had query parameters before PHP3 was released. Maybe it's because the PHP team insists on making the database libraries as close as possible to the C libraries they are based on, but bind parameters (even emulated, client-side ones) are easier to use and less error-prone than escaping the values one-by-one.

If you are writing code and you are using a library you did not write then you are not violating the GPL.

Sigh. You are as wrong as you are ignorant. MySQL converted their client-library licenses to GPLv2 (from LGPL) several years ago. Both the GNU zealots and MySQL believe that any applications which use libraries licensed under the GPL are derivative and thus must be wholly licensed under the GPL. This is not an academic point either as this dual-licensing model is where MySQL has derived most of their revenues from (which, depends, on the GPL's force over client libraries).

From the GPL v2:

"If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License"

From MySQL:

Previously, the MySQL client libraries were licensed under the LGPL (the Lesser General Public License) and now they use the GPL (the General Public License). What prompted this change?
MySQL's goal is to provide all its software under a free software/open source license. The change from the LGPL to the GPL for the client libraries was made in 2001 during the development of MySQL 4.0 to help MySQL AB more easily differentiate between a proprietary user who should buy a commercial license and a free software user who should use the GPL license. Previously there were people that were misusing the GPL by distributing the MySQL server tightly coupled with their applications and claiming that the GPL doesn't affect them because the client libraries were free to use.

This change has allowed MySQL to support its dual licensing model by better identifying when someone is using MySQL software in a closed source fashion without commitment to the open source philosophy. While MySQL supports the open source ideals, we also believe in the notion of "Quid Pro Quo" or fair exchange. For developers building open source applications using MySQL, the change in the client licensing policy has no effect.

Based on feedback from our users, MySQL has introduced an exception that makes it possible to combine the MySQL client libraries with software that uses various Free and Open Source software ("FOSS") licenses. This is known as the FOSS License Exception.

Also from MySQL:

"If you include one or more of the MySQL drivers in your non-GPL application (so that your application can run with MySQL), you need a commercial license for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library."

"If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries."

SO if you are using JDBC, ruby, python, php, ocaml, haskell, rebol, or brainfuck to write your program that access your mysql server you are safe.

Wrong. The GPL affords no such protections. PHP and other open source projects were at risk when they made the change. MySQL had to create a special special exception for these FLOSS programs. A MySQL client-library derivative work (e.g., PHP) is OK as long as the source code is released (under one of the enumerated FLOSS licenses or GPL). MySQL, however, still claims that if you write an application on top of one of these other FLOSS programs, e.g., PHP, and is considered derivative, i.e., connects to MySQL with their libraries, then you must release your source code with your distribution. In other

If you are writing code and you are using a library you did not write then you are not violating the GPL.

Sigh. You are as wrong as you are ignorant. MySQL converted their client-library licenses to GPLv2 (from LGPL) several years ago. Both the GNU zealots and MySQL believe that any applications which use libraries licensed under the GPL are derivative and thus must be wholly licensed under the GPL. This is not an academic point either as this dual-licensing model is where MySQL has derived most of their revenues from (which, depends, on the GPL's force over client libraries).

From the GPL v2:

"If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License"

From MySQL:

Previously, the MySQL client libraries were licensed under the LGPL (the Lesser General Public License) and now they use the GPL (the General Public License). What prompted this change?
MySQL's goal is to provide all its software under a free software/open source license. The change from the LGPL to the GPL for the client libraries was made in 2001 during the development of MySQL 4.0 to help MySQL AB more easily differentiate between a proprietary user who should buy a commercial license and a free software user who should use the GPL license. Previously there were people that were misusing the GPL by distributing the MySQL server tightly coupled with their applications and claiming that the GPL doesn't affect them because the client libraries were free to use.

This change has allowed MySQL to support its dual licensing model by better identifying when someone is using MySQL software in a closed source fashion without commitment to the open source philosophy. While MySQL supports the open source ideals, we also believe in the notion of "Quid Pro Quo" or fair exchange. For developers building open source applications using MySQL, the change in the client licensing policy has no effect.

Based on feedback from our users, MySQL has introduced an exception that makes it possible to combine the MySQL client libraries with software that uses various Free and Open Source software ("FOSS") licenses. This is known as the FOSS License Exception.

Also from MySQL:

"If you include one or more of the MySQL drivers in your non-GPL application (so that your application can run with MySQL), you need a commercial license for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library."

"If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries."

SO if you are using JDBC, ruby, python, php, ocaml, haskell, rebol, or brainfuck to write your program that access your mysql server you are safe.

Wrong. The GPL affords no such protections. PHP and other open source projects were at risk when they made the change. MySQL had to create a special special exception for these FLOSS programs. A MySQL client-library derivative work (e.g., PHP) is OK as long as the source code is released (under one of the enumerated FLOSS licenses or GPL). MySQL, however, still claims that if you write an application on top of one of these other FLOSS programs, e.g., PHP, and is considered derivative, i.e., connects to MySQL with their libraries, then you must release your source code with your distribution. In other

If you are writing code and you are using a library you did not write then you are not violating the GPL.

Sigh. You are as wrong as you are ignorant. MySQL converted their client-library licenses to GPLv2 (from LGPL) several years ago. Both the GNU zealots and MySQL believe that any applications which use libraries licensed under the GPL are derivative and thus must be wholly licensed under the GPL. This is not an academic point either as this dual-licensing model is where MySQL has derived most of their revenues from (which, depends, on the GPL's force over client libraries).

From the GPL v2:

"If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License"

From MySQL:

Previously, the MySQL client libraries were licensed under the LGPL (the Lesser General Public License) and now they use the GPL (the General Public License). What prompted this change?
MySQL's goal is to provide all its software under a free software/open source license. The change from the LGPL to the GPL for the client libraries was made in 2001 during the development of MySQL 4.0 to help MySQL AB more easily differentiate between a proprietary user who should buy a commercial license and a free software user who should use the GPL license. Previously there were people that were misusing the GPL by distributing the MySQL server tightly coupled with their applications and claiming that the GPL doesn't affect them because the client libraries were free to use.

This change has allowed MySQL to support its dual licensing model by better identifying when someone is using MySQL software in a closed source fashion without commitment to the open source philosophy. While MySQL supports the open source ideals, we also believe in the notion of "Quid Pro Quo" or fair exchange. For developers building open source applications using MySQL, the change in the client licensing policy has no effect.

Based on feedback from our users, MySQL has introduced an exception that makes it possible to combine the MySQL client libraries with software that uses various Free and Open Source software ("FOSS") licenses. This is known as the FOSS License Exception.

Also from MySQL:

"If you include one or more of the MySQL drivers in your non-GPL application (so that your application can run with MySQL), you need a commercial license for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library."

"If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries."

SO if you are using JDBC, ruby, python, php, ocaml, haskell, rebol, or brainfuck to write your program that access your mysql server you are safe.

Wrong. The GPL affords no such protections. PHP and other open source projects were at risk when they made the change. MySQL had to create a special special exception for these FLOSS programs. A MySQL client-library derivative work (e.g., PHP) is OK as long as the source code is released (under one of the enumerated FLOSS licenses or GPL). MySQL, however, still claims that if you write an application on top of one of these other FLOSS programs, e.g., PHP, and is considered derivative, i.e., connects to MySQL with their libraries, then you must release your source code with your distribution. In other

The Community download pages give the links to the Community source for the version being made available to the Community. The 5.0.30 version doesn't belong there because it's not the correct version.

If you think MySQL was hiding the 5.0.30 source, I wrote this in a bug report back on 30 November, about two weeks after 5.0.30 was released:

"Those who are not Network/Enterprise or other Support customers can obtain the
Enterprise source code from ftp://ftp.mysql.com/pub/mysql/src when it is
released there"

The current plan is to have a new Community build from MySQL sometime in February. Subject to change, as always, so treat it as "sometime around then".

• We subscribe to the Open Source philosophy and support the Open Source community
• We aim to be good citizens
• We prefer partners that share our values and mindset
• We answer email and provide support
• We are a virtual company, networking with others
• We work against software patents

Somehow, when a company capitalizes on the "commercial" confusion, it doesn't surprise me at all that they would make this "error" (I don't think it's accidental, I mean to suggest they are faking a confusion, as in the "commercial" term, in order to forbid anyone from making a GPL V3 fork of MySQL)

The "commercial" term "confusion" they capitalize upon make many think that in order to make a commercial application they would have to get the proprietary version of MySQL.

That, of course, makes no sense at all. The FSF explains it very succintly, and David Wheeler quite recently explained it in a very detailed manner.

InnoDB does not appear to be ACID-compliant, at least according to the ANSI standard. See:
http://dev.mysql.com/doc/refman/5.1/en/innodb-erro r-handling.html

See the 2nd bullet point. Silently accepting some statements in a transaction while discarding others is a pretty bad idea.

As for another new storage engine coming out soon: MySQL and NitroSecurity have also recently announced that they are working together to integrate NitroEDB into MySQL as a storage engine, promising high-speed insertion and query rates even using VLDB data volumes.

Which is what everyone says. That shows that you don't know anything about the present-day Linux desktop. Question: what mainstream app is missing from the business computing desktop environment?

1. Microsoft Outlook?Evolution and Kontact replace Outlook quite handily. Evolution can use the Evolution-Exchange Connector to communicate through Outlook Web Access (which many Enterprises enable anyway) and provide full Outlook functionality in Evolution. Kontact can use full Outlook functionality if configured correctly (not so user-friendly, but still quite possible). In addition, the junk mail filtering is better, using the locally installed SpamAssassin filter.
2. Microsoft Office?All but the most complex spreadsheets and Word documents can be handled by OpenOffice without any problem. I doubt that the complex ones even pose that much difficulty in migration. Microsoft Access is still used in some minor applications, but it's trivial to import the data to another, better RDBMS. There are several free GUI clients for managing the new database. MySQL has good desktop database solutions. You'd have to use pretty much every proprietary feature in Access to have this be a sticking point.
3. Internet Explorer?Ah, yes. The basis of the antitrust suit. I admit that if your organization went out of its way to find webapp software that worked only in IE, you might have some migration issues. However, IE6 runs quite well under emulation on recent versions of WINE, so unless that ActiveX component they chose is really screwed up, there's a good chance you can even emulate that. JavaScript migration issues are less of a problem than they used to be (another favourite sticking point) so Firefox will likely work well for a lot of apps that weren't designed to protect Microsoft's monopoly.

Well, the list goes on. Custom-written software (could work well under emulation unless designed specifically to thwart WINE), IP Telephony (Skype has a Linux client), and so on. My point is that any business that's interested could switch today if they wanted. There's no missing killer app (unless you're trying to make excuses). The roadblocks to migrating entirely to Linux on the business desktop are all artificially created by Microsoft to protect their monopoly. The most difficult part is convincing your users that it's a good choice. They've been brainwashed by years of Microsoft marketing, and believe pretty much every word that comes out of Steve's and Bill's mouths blindly. Many organisations will encounter significant resistance during training as belligerent, brain-washed Microsoft junkies demand that things go back to the way they were. That's unfortunate, because I can finally say after almost 15 years of using Linux, that using a Linux desktop is a joy, not an arduous task that requires command-line hacking to accomplish everything it can do.

Well, I had previously found a more specific FAQ about the client libraries back when I was helping research the licensing stuff. I can't find it now, but this excerpt from the commercial license page seems applicable (from http://www.mysql.com/company/legal/licensing/comme rcial-license.html).

"If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries."

"If you include one or more of the MySQL drivers in your non-GPL application (so that your application can run with MySQL), you need a commercial license for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library."

That was changed over a year ago.

And is there a problem with the current mysql implementation of foreign keys?

Those are additions to the standard (extra features for those who need them). Dollar quoting is useful because PostgreSQL treats stored procedure code as strings. Without dollar quoting, you would have to play delimiter games or escape every single quote inside the stored procedure to create stored procedures. And about the C comments, doesn't MySQL have those too?

About case-sensitivity in table names... I thought that was only about the case folding? (PostgreSQL stores unquoted table names in lowercase, the SQL standard specifies uppercase), see 4.1.1

Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)

From the MySQL 5.0 manual:

InnoDB tables support checking of foreign key constraints. See Section 14.2, "The InnoDB Storage Engine". Note that the FOREIGN KEY syntax in InnoDB is more restrictive than the syntax presented for the CREATE TABLE statement at the beginning of this section: The columns of the referenced table must always be explicitly named. InnoDB supports both ON DELETE and ON UPDATE actions on foreign keys. For the precise syntax, see Section 14.2.6.4, "FOREIGN KEY Constraints".

For other storage engines, MySQL Server parses and ignores the FOREIGN KEY and REFERENCES syntax in CREATE TABLE statements. The CHECK clause is parsed but ignored by all storage engines. See Section 1.9.5.5, "Foreign Keys".

Oh look, ignoring constraints without a warning! You said:

Well, if you can argue that, then "missing foreign key constraints is a feature, not a bug!"

The bad things about MySQL (to me at least) aren't about the nonportable extra features (they can be convenient, but makes it harder to switch databases), but about the features that it lacks (like, you know, proper support for constraints...)