Slashdot Mirror

On a database server, if it's highly used, is largely stuck on the slowest part (disk i/o) when it has to do full table scans. You solve this by building proper indexes

Until you have to use a DBMS that ignores your indexes. For example, MySQL appears unable to make efficient use of an index on a subquery that uses GROUP BY. From the manual: "A subquery in the FROM clause is evaluated by materializing the result into a temporary table, and this table does not use indexes. This does not allow the use of indexes in comparison with other tables in the query, although that might be useful." The only reason I haven't already rewritten it as a join is that the subquery uses GROUP BY. The workaround I have adopted is to rewrite the query as multiple CREATE TEMPORARY TABLE ... SELECT statements so that as few rows at possible are seen at once. Or is there a better workaround, other than dropping MySQL entirely?

COUNT(*) includes null values. COUNT(1) counts all rows where 1=1, which would include null rows. On a modern RDMBS, they're synonymous.

"COUNT(*) is somewhat different in that it returns a count of the number of rows retrieved, whether or not they contain NULL values. " See MySQL 5.5 Reference. Or Microsoft SQL Server saying "COUNT(*) returns the number of rows in a specified table without getting rid of duplicates. It counts each row separately. This includes rows that contain null values.". Asktom remarks, for Oracle, (when asked what the difference is) "nothing, they are the same, incur the same amount of work -- do the same thing, take the same amount of resources."

(Apparently in Oracle 7 and below, COUNT(1) had performance advantages over COUNT(*). I have no idea why.)

(I prefer COUNT(*) because it makes it especially clear I'm really not caring what the value is.)

I don't know exactly what the ANSI spec says, but I assure you that MySQL, Oracle and MSSQL all treat them the same.

And don't forget one of the most performent methods for handling trees in SQL...nested sets.

http://dev.mysql.com/tech-resources/articles/hierarchical-data.html

MySQL Workbench. http://wb.mysql.com/

I take it you meant Access connecting to MySQL through ODBC, did you not?

http://www.mysql.com/about/legal/licensing/oem/

Q6: What is Oracle's commercial license for MySQL software?

A: Oracle offers a commercial license for all of its MySQL software that is embedded in or bundled with another application. The commercial license allows OEMs, ISVs and VARs to distribute commercial binaries of MySQL software with their own commercial software without subjecting that software to the GPL and its requirement to distribute source code.

Or how about taking 5 years to allow variables to be used in the LIMIT clause, I mean, who would want that after all? Not like anyone needs dynamic pagination with stored procedures or anything except, I don't know, people who need to get shit done properly.

... but have they fixed that annoying Server Locks with "Copying to tmp table" problem?

The problem that's been around for at least five years. The problem that the MySQL devs dismissed as unimportant and "it's fixed in 6 Alpha, so, like... install that alpha software into a production environment because we're too incompetent/lazy/arrogant to backport the fix. Performance is way more important than, I dunno, doing the basics right." The problem that has crazy workarounds like removing indeces.

I had the misfortune of sysadminning a bugzilla server at a medium size telco, and every day I was restarting mysqld because of that issue. I had highly strung senior developers breathing down my neck because MySQL's shittiness was somehow my fault (even though it was the devs who chose and insisted on MySQL, when we could have used Oracle - we were almost literally drowning in licences). We had independant DBA's give all the queries etc a fine tooth comb and it was all ok on that side, it was just MySQL being a useless pain in the arse. Eventually I wrote a small script that checked the MySQL status every couple of minutes, and if it saw "copying to tmp table" it immediately restarted mysqld. That company also had a MS SQL server, and apart from the odd patch and upgrade here and there, it was immensely less painful to admin than MySQL - what does that tell you?

How pleasant then, to move on to a 6 month contract at a role that used primarily PostGres. They had one MySQL server box that I was constantly nursing along (mostly my predecessor's fault for leaving in the default InnoDB settings, which is another rant altogether) and I had not one peep from any of the PostGres boxes. They simply just worked (tm).

I am not an experienced DBA, I'm just a garden variety Nix Admin. I personally don't care much for the finer points between LEFT JOIN's and such. Nor am I a PostGres/Oracle/MS-SQL/other fanboy, but results speak for themselves, and the results are: MySQL is a steaming piece of turd. If they've fixed the above 5 year old issue, then I might change my tune, but for now with far superior options out there, I wonder why anyone is still bothering with MySQL? The only real upside is that nursing MySQL along keeps me employed, but anyone can just wget mysqltuner.pl and do a decent enough job nursing MySQL along...

... but have they fixed that annoying Server Locks with "Copying to tmp table" problem?

The problem that's been around for at least five years. The problem that the MySQL devs dismissed as unimportant and "it's fixed in 6 Alpha, so, like... install that alpha software into a production environment because we're too incompetent/lazy/arrogant to backport the fix. Performance is way more important than, I dunno, doing the basics right." The problem that has crazy workarounds like removing indeces.

I had the misfortune of sysadminning a bugzilla server at a medium size telco, and every day I was restarting mysqld because of that issue. I had highly strung senior developers breathing down my neck because MySQL's shittiness was somehow my fault (even though it was the devs who chose and insisted on MySQL, when we could have used Oracle - we were almost literally drowning in licences). We had independant DBA's give all the queries etc a fine tooth comb and it was all ok on that side, it was just MySQL being a useless pain in the arse. Eventually I wrote a small script that checked the MySQL status every couple of minutes, and if it saw "copying to tmp table" it immediately restarted mysqld. That company also had a MS SQL server, and apart from the odd patch and upgrade here and there, it was immensely less painful to admin than MySQL - what does that tell you?

How pleasant then, to move on to a 6 month contract at a role that used primarily PostGres. They had one MySQL server box that I was constantly nursing along (mostly my predecessor's fault for leaving in the default InnoDB settings, which is another rant altogether) and I had not one peep from any of the PostGres boxes. They simply just worked (tm).

I am not an experienced DBA, I'm just a garden variety Nix Admin. I personally don't care much for the finer points between LEFT JOIN's and such. Nor am I a PostGres/Oracle/MS-SQL/other fanboy, but results speak for themselves, and the results are: MySQL is a steaming piece of turd. If they've fixed the above 5 year old issue, then I might change my tune, but for now with far superior options out there, I wonder why anyone is still bothering with MySQL? The only real upside is that nursing MySQL along keeps me employed, but anyone can just wget mysqltuner.pl and do a decent enough job nursing MySQL along...

Ok, just googled "mysql profile" and got:

http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html

Actually, it's probably an ENUM. Which would mean it could have 65,535 possible values.

Source:

http://dev.mysql.com/doc/refman/5.0/en/enum.html

string management and validation.

...is at the application level. Though MySQL has plenty of string functions available if necessary.

Ease and certainty of restoring backups.

This one might have a bit of truth to it.

Comprehensibility of documentation

I dunno, the official documentation is pretty comprehensive.

Decently organized functions.

If you're talking about stored procedures, maybe. Otherwise, MySQL is ANSI compliant for the most part, so very little should be new.

A major effort at ironing out bugs, quirks, and exceptions to rules. Gawd, PHP is just a horror, and end users hate Java and Javascript, what a mess those versions are. Who the hell has time to overhaul their applications every time the publishers of PHP scratch their asses?

And here you've gone off on PHP when I asked specifically about the database, and the rest of your issues follow suit.

Databases are data entry applications, that means keyboard navigation. Keep your hands on the keyboard. The graphical mouseable interface is just death.

Nope. Databases are databases. Data entry applications query a database. Like I said, if you want a purely text interface, you're welcome to code your own in C. MySQL isn't tied to PHP in any way.

I could see your point if MySQL weren't being used in some high-profile instances. However, even that isn't the case anymore. For instance, Google has submitted quite some patches of its own to MySQL.

See MySQL's case studies here: http://www.mysql.com/why-mysql/case-studies/

Disclaimer: I am not in any way related to MySQL as more than a web developer. I'm even contemplating a move to PostgreSQL somewhere down the road due to the recent Oracle shenanigans. But nowadays, it is a pretty good product.

From what I know, the Microsoft offering is not feature complete, a bit like their free-text search indexing in SQL server, its always a step behind Oracle's. I know we use Oracle for its spatial capabilities because the SQL server doesn't quite cut it for the really cool stuff.

For free versions - MySQL has spatial in it for some time. That's still free, and hopefully Oracle will improve the capabilities if only to annoy MS and capture the market that you represent - the 'we want it free until we have to buy something, and then that'll probably be Oracle' segment.

And on top of that, just try writing a query for hierarchical data! You'll have sub-selects for each level of hierarchy. This means in order to to something relatively simple, like KPCOFGS of species classifications, you'll need a select and 6 sub-selects. At least that one is well defined to . If its not, you just don't know how many, and you have to write a recursive function to generate your select query, or process the results from it. Either way, you repeatedly consider 99% useless records at every level. True, you can cheat at this because there are always 7 levels. But that is not true for most other trees.

This is true if you use the Agency List Model for hierarchical data. Nested Set Models are a better solution to storing hierarchical data and are extremely fast and efficient for selecting arbitrarily deep nested data without tons of sub-selects. Though inserts are slow in theory (because you have to re-balance the tree) there are practical ways of inserting data so performance doesn't suffer.

See the MySQL site for their discussion of the Nested Set Model, this article on the same topic by Joe Celko and a question about insert performance in which Celko responds.

sql = malloc(ONE_MEG);
sql = sprintf(%s;%s;%s;%s;%s;%s;%s;%s ...", query1, query2, query3, query4, query5 ....);

Basically, any thread that had a request added it to the string. A thread might have 10 different selects. Why not do them all at once, along with 50 other threads?

Put 1000 queries into that single string, then call the c api to execute it. Then "peel off" the results. You can't do this with php, and you may have some difficulty doing it with java (I'd have to check the API), but under c with mysql, it works like you wouldn't believe. A word of caution - use ON DUPLICATE KEY as much as possible - this way, if you have two statements that would both try to append the same key value, you can use the latter one to do an update. This solves the biggest problem of multiple-statement execution. Unfortunately, pg doesn't have on duplicate key yet.

Obviously made-up example "insert into users (name, id, access_time) values "blah" "blah" "blah" on duplicate key update users set access_time=now() where id="id" limit 1";

"on duplicate key" is one of those miracle statements - when you need it, it works miracles.

Looking at the pglibs it isn't able to return everything for a multi-statement query, only the last result - darn, that kind of sucks, but it can still be useful - for example, you might have 4 or 5 inserts, a few updates then a select. You could do them all, saving the select as the last statement so you get the results. "insert into blah; insert into foo; insert into yuck; update sess; select from pages;" would return your select (or an error if a previous statement failed).

Here's the docs for mysql c api multiple-statement execution and result retrieval.

BTW - since everyone's been on my case claiming that "java can be faster than c" and that "gcj compiles code" I figured I'd , and I also tested gcj and took a look at the "compiled" program.

Java has its place, but not where you need high performance. It's a dog, really :-)

Are you referring to this?

It reads as if they were pretty close to completing implementation of IPv6 in MySQL. It's disappointing that they haven't already done it, but I rather expect the priority will go up if it becomes more of a problem.

MySQL 5's Fulltext index with the "natural language search" option might do everything you need with almost no overhead. That, plus PHP's PDO to connect to the database, and I think you might be done. How much data are we talking, anyhow? 10,000 magazine articles or less?

The future of MySQL is iffy, too. All Oracle has to do is put the second team on maintaining it, and it will die. A database program has to be very reliable to be usable at all.

We've already seen this with "MySQL Workbench". Since Oracle took over, all the MySQL GUI tools were wrapped into a central "MySQL Workbench" program. Which crashes frequently. (If you can install it at all.) If Oracle can bring MySQL down to the level of MySQL Workbench, nobody will be able to use it.

MySQL needs to be fully archived, including the revision history, outside of Oracle, just in case.

Any particular reason you linked to an older version of the documentation? :D

http://dev.mysql.com/doc/refman/5.5/en/c-api-multiple-queries.html

" As of MySQL 5.5.3, CLIENT_MULTI_RESULTS is enabled by default."

Anyway, there are a million reasons to sanitize input before doing ANYTHING with it, SQL injection is only one of them. Ppl blaming the DBs for these kinds of things probably had a server or 50 FUBARed and really want to be somewhere else right now.

As I indicated earlier, MySQL has an option for this, but does not do it by default.

I stand corrected on PostgreSQL. Apparently, the developers showed the same lack of foresight as the Sybase / MS SQL developers did. Or perhaps bad ideas are contagious.

In any case, all the databases that support this behavior ought to deprecate and disable it, because in the real world, it is an invitation for severe problems. Sort of like opening root shell access to a random passersby by accident.

You can do it, yes. But it an option you have to turn on. The MySQL developers are not yet so clueless as to enable it by default.

See http://dev.mysql.com/doc/refman/5.0/en/c-api-multiple-queries.html

And discussion also spells out why this wouldn't likely happen in a LAMP scenario -- no multiple query commands by default.

This statement is not entirely true. If you see MySQL and PostgreSQL documentation you'll see that both support the same sort of technique. Different frameworks may try mitigate (some versions of PHP may take a dim view to multiple statements in a single query for MySQL as an example, but the PHP docs for Postgre say that PgSQL will in fact run every statement you include in your query).

Really? I didn't realise that MySQL and PostgreSQL weren't databases!

Not even close. MSSQL and Sybase are the only databases that are vulnerable to this form of SQL injection (in combination with sloppy programming).

Really? I didn't realise that MySQL and PostgreSQL weren't databases!

Sorry. There are no databases other than MS SQL, Sybase, and derivatives that allow the injection of an entirely new SQL statement where a literal belongs. It is due to the way they support combining multiple statements separated by semicolons.

Wrong.

http://dev.mysql.com/doc/refman/5.0/en/c-api-multiple-queries.html

Also:

http://www.postgresql.org/docs/6.4/static/install12418.htm

"(Get in the habit of including those SQL semicolons. Psql won't execute anything until it sees the semicolon or a "\g" and the semicolon is required to delimit multiple statements.)"

I hear our dba's complain about replication too. We run services on both mysql and postgresql and from what I gathered it was far more difficult and error prone to configure the replication for complex posgresql databases (defining per table?).

Well of course replication on a complex database is going to be hard. Fact is, most MySQL databases are very simple (the only appropriate use of MySQL, IMHO). Once a MySQL database gets complicated, it is all but impossible to coax robust replication out of it. In the case of one I had to deal with, I had to finally retreat to the simplest master->slave approach, AND I had to upgrade to 5.1 for row-base replication (statement-based replication is just impossible if you have complex stored procedures). Even so, I have to set slave_exec_mode to IDEMPOTENT in order to actually keep replication running, which of course makes the actual replication far less robust. (I know, if they moved to full transactional INNODB tables it probably wouldn't be necessary, but unfortunately they need MyISAM tables for some things).

Point is, replication is HARD to get right on any moderately complex system. I doubt there will ever be a magic bullet in that regard.

Yes you can, but there seems to be a bit of difference between how Mysql and PostgreSQL define Repeatable read. According to postgresql (http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html) the repeatable read does allow phantom read(That is: The same select executed in the same transaction can give 2 different results). According to mysql http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_repeatable-read) this is not allowed in mysql.

If you want to avoid phantom-read in postgresql you need to specify the Serializable level, which seems to be same as repeatable read in mysql.

Oh and a funny fact: Postgresql don't have a specific repeatable read level, so if you request it, you will get Serializable but this is i guess subject to change.

What does an HTTP server have to do with a DB?

PostgreSQL has a lot of more enterprisy features than MySQL.

You mean like clustering?

Oh, wait...

How about proper ACID compliance?
Not null constraints?

Of course, if you talk to MySQL users you soon realise most won't consider anything an "enterprisy feature" until it is supported by MySQL.

I nearly fell off my chair a while ago when I read the changelist for the last major MySQL release trumped the exciting new ability to do *online database backups*.

I mean, seriously? lets not kid ourselves, MySQL has its uses as a quick and dirty database, can be fast if you stay away from the slow bits (things like joining more than a couple of tables together, or concurrent updates) but its an enterprise database in the same way MS Access is.

http://dev.mysql.com/doc/refman/5.1/en/information-functions.html contains some instructions for "simulating sequences". So I guess that's a no.

Actually, MySQL doesn't. At least not with InnoDB:

"InnoDB uses the following algorithm to initialize the auto-increment counter for a table t that contains an AUTO_INCREMENT column named ai_col: After a server startup, for the first insert into a table t, InnoDB executes the equivalent of this statement:

SELECT MAX(ai_col) FROM t FOR UPDATE;

InnoDB increments by one the value retrieved by the statement and assigns it to the column and to the auto-increment counter for the table. If the table is empty, InnoDB uses the value 1"

What does an HTTP server have to do with a DB?

PostgreSQL has a lot of more enterprisy features than MySQL.

You mean like clustering?

Oh, wait...

In 2005, venture capital investors who had backed (among others) eBay and Skype - and meanwhile also Twitter - supported my last-minute lobbying effort in the European Parliament against the EU software patent directive. The related press release mentioning Benchmark Capital (eBay, and more recently Twitter) and Danny Rimer of Index Ventures (Skype) is still online on the MySQL website although Oracle and Sun certainly do favor software patents. Guess they forgot to delete it. Other references to MySQL's position on software patents disappeared after Sun bought the company in 2008.

Those venture investors had previously supported an open letter to EU decision-makers warning against the possible consequences of an adoption of the proposed bill (which ultmately got thrown out, fortunately).

However, I also got turned down by many venture investors whom I asked to support such initiatives against software patents. I don't think the resistance movement is strong enough in economic and political terms to achieve the abolition of software patents anytime soon. I regret to say so but the hurdle is high and politicians won't be convinced if it's basically just the Free and Open Source Software movement that takes political action against software patents. A few venture capitalists won't tilt the scales either. There would have to be broadbased support. In Europe, the leading venture capital organization (EVCA) actually lobbied for the legislative proposal we fought against. I guess the major American venture capital associations would take similar positions.

In the near to mid term, I believe the Defensive Patent License (DPL) could have a very positive effect.

Maybe you didn't read the MySQL licence... "Sun makes its MySQL database server and MySQL Client Libraries available under the GPL for use with other GPL-licensed software and FOSS applications licensed under GPL-compatible FOSS licenses. In addition, for open source projects and developers creating and distributing open source software under certain FOSS licenses other than the GPL, Sun makes its GPL-licensed MySQL Client Libraries available under a FOSS Exception that allows distribution of the FOSS application with the MySQL Client Libraries without causing the entire derivative work to be subject to the GPL." and keep reading it at MYSQL site
Any software project that does not fit in the above description must pay a licence.

I don't have time to look this up at the moment, but what I recall as the most important and least conventional GPL interpretation is that MySQL (the company) took the position that applications that depended on MySQL (the RDBMS) as one of their components were derivative works that incorporated the RDBMS--and that details about linking or protocols were just not relevant. Therefore, unless you bought a commercial license from the company, such applications had to be distributed under GPL terms.

Not quite. The client library is GPL licensed, so any app that links the client library has to be GPL.

This does not apply to PHP apps that use the PHP native driver (mysqlnd) as that was developed by PHP devs who wanted a PHP licensed (BSD like) MySQL driver.

Presumably, there is nothing stopping anyone else who wants to from developing their own BSD licensed client or client library (they could probably reuse at least some of the mysqlnd devs work). The fact that it has not happened probably demonstrates that not all that many people want to bundle MySQL with a closed source app.

So the lesson here is one should not put too much stock on arguments about static vs. dynamic linking, linking vs. network protocols, or other such technical details, because judges will most likely find that none of those details are really the essential issue.

Interesting, thanks for that link. I had often wondered whether judges were likely to decide it on a purely technical point, without taking intent, level of integration etc, into account, it looks like not. This works both ways: in some circumtances it weakens the FSF position that any software than runs in the same process is a derivative work.

You might want to look at MySQL Workbench. I've been messing with it a bit for a couple weeks and really like it so far. I'm running it on Fedora but there is an OSX release.

What, you aren't already?

Funny thing: MySQL's website says

The world's most popular open source database

PostgreSQL's website says

The world's most advanced open source database

I've always preferred PostgreSQL over MySQL ;-)

As long as the software/library is written completely by yourself, you're free to pick any license -- or dual-license it.

You can have your program both licensed under BSD, and also offer the same code/library as closed-source for $xx at the same time, with different conditions and fewer restrictions.

An example of other software that uses the dual-licensing approach is MySQL: for more information see http://www.mysql.com/news-and-events/newsletter/2003-11/a0000000220.html

Truthfully though, where the heck are the meta-data based filesystems that we were promised? I've love to be able to, on a filesystem level, instantly pull up a folder view of all videos - or all images. Or all images of my dog. Or all images outdoors. Or all images of my dog outdoors.

Here ya go.

The product contains MySQL[tm] under GPL and Gemini. Gemini is statically linked to the MySQL code. This means that Gemini needs to be under GPL as well, but it is not.

No problems with invalid data types if you bother to RTFM and setup the config properly. (It's not hard. Just turn strict mode on.)

Strict mode is a client setting, which means that you're always at the mercy of applications turning it off and inserting garbage. And there's the "IGNORE" keyword to allow that too. There is no way to make a MySQL server reject all incoming bad data.

Can you elaborate on the 'correct' with emphasis?

Google says that both postgresql and mysql get hits from 'incorrect results'. Are you stating that mysql's bugs have gone unfixed while postgre's have not? Or what?

For fairness, I'm going by MySQL version 5.5, the development version.

The default storage engine will quietly ignore foreign key constraints and transactions. source for default engine, claim that MySQL parses and ignores for non-InnoDB

There are multiple "SQL Modes" that can alter correctness, source, but by default the DBMS doesn't try to validate input. It's pretty confusing what mode does what, and I don't care enough to figure it out, but MySQL's approach has always been Do What I Think You Mean, and if they set the new version to be ANSI compliant by default it'd break all the existing sites built on it.

(I'm claiming this qualifies as "not being correct" by virtue of the Information Principle. Granted, SQL itself violates it in many ways, but MySQL proved that you can do worse than SQL.)

PostgreSQL has a far more correct transaction model. In some ways, they're actually better than Oracle. (In Oracle, a DDL statement will start a new transaction, whereas PostgreSQL wraps DDL into a transaction.) For starters, there aren't multiple "storage engines" per table with different transactional behaviors. source, sort of.

Also, PostgreSQL, to my knowledge, correctly validates input. It's kind of hard to cite a source for this since there's just no FAQ entry "Q. How do I configure PostgreSQL to silently corrupt my data? A. You can't." But by the same token, they don't have any long-standing terrible design decisions that they have to maintain compatibility with.

Can you elaborate on the 'correct' with emphasis?

Google says that both postgresql and mysql get hits from 'incorrect results'. Are you stating that mysql's bugs have gone unfixed while postgre's have not? Or what?

For fairness, I'm going by MySQL version 5.5, the development version.

The default storage engine will quietly ignore foreign key constraints and transactions. source for default engine, claim that MySQL parses and ignores for non-InnoDB

There are multiple "SQL Modes" that can alter correctness, source, but by default the DBMS doesn't try to validate input. It's pretty confusing what mode does what, and I don't care enough to figure it out, but MySQL's approach has always been Do What I Think You Mean, and if they set the new version to be ANSI compliant by default it'd break all the existing sites built on it.

(I'm claiming this qualifies as "not being correct" by virtue of the Information Principle. Granted, SQL itself violates it in many ways, but MySQL proved that you can do worse than SQL.)

PostgreSQL has a far more correct transaction model. In some ways, they're actually better than Oracle. (In Oracle, a DDL statement will start a new transaction, whereas PostgreSQL wraps DDL into a transaction.) For starters, there aren't multiple "storage engines" per table with different transactional behaviors. source, sort of.

Also, PostgreSQL, to my knowledge, correctly validates input. It's kind of hard to cite a source for this since there's just no FAQ entry "Q. How do I configure PostgreSQL to silently corrupt my data? A. You can't." But by the same token, they don't have any long-standing terrible design decisions that they have to maintain compatibility with.

Can you elaborate on the 'correct' with emphasis?

Google says that both postgresql and mysql get hits from 'incorrect results'. Are you stating that mysql's bugs have gone unfixed while postgre's have not? Or what?

For fairness, I'm going by MySQL version 5.5, the development version.

The default storage engine will quietly ignore foreign key constraints and transactions. source for default engine, claim that MySQL parses and ignores for non-InnoDB

There are multiple "SQL Modes" that can alter correctness, source, but by default the DBMS doesn't try to validate input. It's pretty confusing what mode does what, and I don't care enough to figure it out, but MySQL's approach has always been Do What I Think You Mean, and if they set the new version to be ANSI compliant by default it'd break all the existing sites built on it.

(I'm claiming this qualifies as "not being correct" by virtue of the Information Principle. Granted, SQL itself violates it in many ways, but MySQL proved that you can do worse than SQL.)

PostgreSQL has a far more correct transaction model. In some ways, they're actually better than Oracle. (In Oracle, a DDL statement will start a new transaction, whereas PostgreSQL wraps DDL into a transaction.) For starters, there aren't multiple "storage engines" per table with different transactional behaviors. source, sort of.

Also, PostgreSQL, to my knowledge, correctly validates input. It's kind of hard to cite a source for this since there's just no FAQ entry "Q. How do I configure PostgreSQL to silently corrupt my data? A. You can't." But by the same token, they don't have any long-standing terrible design decisions that they have to maintain compatibility with.

    You have to provide references before saying something like that. :)

    It was $1B in total considerations, which most likely wasn't all cash. I'm sure all of it didn't go in Monty's pocket, but I'm sure he did walk away with a pretty nice sum.

    There's a thing about business though. Most places want to grow a business from nothing, to the point where it's a viable product to sell. Then they sell it. All of it. There's no looking back. It was yours, now it's not. So sorry, move on.

    If I made something, and it sold for $1B, I'd be a pretty happy camper. Hell, Sabeer Bhatia sold Hotmail in 1997 for $400M, and he was happy. Now (in a 2007 article I read), is funding new startups with the hope of making the next killer app that will be bigger than Hotmail.

    I have a few things that I've done, and if someone offered me even $1M to give one up, I'd take it. I wouldn't look back. I'd smile the whole way to the bank. :)

    If he wants MySQL back, tough. If Sun decides to gut it, and make the MySQL site into a porn link farm web site, and the database engine into a shell script that greps a flat file, so be it. It's theirs, and it's their decision. They could sell to Oracle, or Microsoft, or anyone they'd like.

    If he *really* wants it back, he should put his effort into his new database, and don't give it up next time, even for $1B.

I'm not allowed to use any GPL stuff anywhere unless it absolutely, positively will never leave the intranet.

If you run a publicly accessible web site on a LAMP server, the only GPL programs involved are Linux and MySQL, and no copy of Linux or MySQL leaves your server. If you run a web site, only two kinds of programs are ever "distributed" (GPLv2) or "conveyed" (GPLv3) to the public: 1. in-page scripts written in JavaScript, ActionScript, or Java, and 2. software packages explicitly offered for download.

As far as I understand, MySQL AB doesn't (or once did not) agree with your understanding.

http://lists.mysql.com/mysql/198707

The biggest bottle neck is probably data access, in which case the language really doesn't make much, if any difference.

Wrong - the language makes a huge difference. Try using the c api and CLIENT_MULTI_RESULTS and CLIENT_MULTI_STATEMENTS and concatenating 10,000 queries into one request, then using mysql_next_result() to get the next result set (no, not the next row, the next result set - 0 or more rows).

One connection. Not 10,000. A BIG difference in execution time. Testing showed that the optimum amount of strcat()ed or fsprintf'd queries was between 10,000 and 20,000 on hardware with limited resources (half a gig of ram, single cpu).

If each page requires 50 hits on the database, you're going to see a big difference.

Now imagine this on a machine with much more ram and more than one core.

More reading: http://dev.mysql.com/doc/refman/5.0/en/mysql-next-result.html

Here's another link with a better explanation and a nice pretty picture :)

How about using DRBD for Mysql High Availability clustering instead of NDBCLUSTER? In a nutshell, one DB instance is used to handle writes and this is synchronously replicated to a Heartbeat cluster standby node using DRBD. Asynchronous replication to more DBs handle all the reads (with load balancing between them). Use Sharding to scale out when you need more capacity.

Certainly Eventum from MySQL, and it's highly recommended