Slashdot Mirror

http://www.mysql.com/why-mysql/case-studies/

PokerRoom.com Powers High Transaction Online Poker System with MySQL and HP .... 12,000 players occupy the poker tables. Since each bet, each played hand and other data are recorded, the database often handles 2,000 transactions per second.

Los Alamos National Labs Relies on MySQL to Scale with 7 Terabytes of Data.

Lycos Europe Reduces TCO by 90% by Migrating to MySQL.

Lycos Europe migrated all company portal services to MySQL, displacing one of the leading proprietary databases in the market. Replacing their existing database solution with MySQL resulted in more than a 90% savings. Lycos Europe today has approximately 1 terabyte of data handled by 100 MySQL servers. At peak traffic up to 25,000 concurrent users are online and 1 Gb of data per second is delivered to users.

Cox Communications Powers Massive Data Warehouse with MySQL To maintain optimum performance and customer-service levels, Cox has developed a huge data warehousing application. At the heart of this business-critical system is a 2-billion row MySQL database.

etc.....

Like these or these?

Like these or these?

I stopped reading your poorly-researched drivel with this line: "MySQL AB was formed in 1994 by Marten Mickos."

Mr. Mickos was not a founder, and did not join the company until 2001. See http://www.mysql.com/company/management.html

Ah, but, see, MySQL AB makes its revenue by spreading exactly that FUD.

Yes, you can use MySQL legally in a commercial app without buying a license. You aren't linking to it. However, MySQL says that you *do* need a license. Enough people are going to be scared enough to buy a license. Open source people just see "GPL -- okay, must not be evil" and go ahead and use it.

This is why I use Postgres and avoid the whole ugly thing.

In their simplest form, the following are general licensing guidelines:

        * If your software is licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, then use our GPL licensed version.
        * If you distribute a proprietary application in any way, and you are not licensing and distributing your source code under GPL, you need to purchase a commercial license of MySQL
        * If you are unsure, we recommend that you buy our cost effective commercial licenses. That is the safest solution. Licensing questions can submitted online for our advice, and we encourage you to refer to the Free Software Foundation or a lawyer as appropriate.

3. Commercial use for everyone else

If your application is not licensed under GPL or compatible OSI license approved by MySQL AB and you intend to distribute MySQL software (be that internally or externally), you must first obtain a commercial license to the MySQL software in question.

More specifically:

a) If you include the MySQL server in your non Open Source application, you need a commercial licence for the MySQL server

b) If you include one of the MySQL drivers in your non Open Source application (so that your application can run with MySQL), you need a commercial licence for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library.

c) If you use MySQL Software within your organisation and you don't want to risk it falling under the GPL license, you are welcome to purchase a commercial license.

d) Many users opt for the commercial licence simply because under it MySQL AB takes responsibility for its products. Under the GPL licence, there are no warranties or representations from the developer (i.e. from MySQL AB).

Wouldn't oracle mode firebird or maxdb or ingres be a bigger threat to oracle them mysql?

What would killing mysql accomplish when ther are a plethora of great open source databases that are fully transactional, full featured and proven in some of the largest companies in the world?

Just two days ago MySQL announced that several companies, including SAP, Intel and Red Hat, had provided US$18.5 million in funding for MySQL. That's long after the InnoDB acquisition and well after the rumors of Oracle buying Sleepycat. Seems really unlikely that they would do that if they weren't confident that MySQL was in a good position anyway.

If you think MySQL is only for the low end you've probably been reading too many posts from those touting a certain other open source database who pop up and criticise MySQL whenever it's in the news. :)

My bet is that within 3 months of oracle flexing their muscles with SleepyCat (remember they haven't done anything yet) Mysql will move MaxDB into the standard mysql distribution and converting will probably just be a dump and reload operation. Why do you think Mysql has suddenly developed stored-procedures, view, and sub queries in such a short period of time?

MaxDB is the SAP database and SAP are investors in Mysql AB.

Microsoft Access! 0_o

First, they're outsourcing more work to India, according to printed reports in the Wall Street Journal (not free, so no link). Hence the reductions.

Secondly, they're getting their hat handed to them by MySQL. I attended (via webcast) a MySQL introduction, and probably 90 percent of the online chat Q&A was from Oracle Developers and DBAs like me asking about migration from Oracle and tutorials on the same, as well as differences such as the more TSQL-based triggers (instead of the PL/SQL ones that I learned first).

Thirdly, my guess is their CEO wants to buy a new boat to race in the America's Cup with ...

Whoever you paid for your commercial MySQL or PostgreSQL support contract, of course.

There are many Oracle, SQL Server and DB2 specialists on the market.

So your contention is that a high rate of turnover in the support of those applications is good?

As an early adopter of software you take on the risk while others (including competitors) learn from your mistakes.

MySQL and PostgreSQL were publically released 11 and 17 years ago, respectively. If that's your idea of "early adopter", then may I also suggest other hip new technologies you might wish to investigate, such as TCP/IP, VGA graphics, and transistor-based memory?

I'd be more comfortable running a system running a vendor dbms rather than an Open Source implementation - just because when shit hits the fan (which it invariably does), at least there's ultimately someone responsible for it.

But MySQL is a vendor DBMS if you want it to be. You can buy the product and support from MySQL.com.

However, even if we invent a hypothetical Open Source product where paid support isn't available, there are circumstances where I get really fed up of the "we can't use that, what if it breaks" attitude.

I've just moved from horrifically risk averse backwater within a Fortune 500 corporation, to an environment where maybe just once in a while you can say "No, you don't need paid support for that piece of Open Source software: if it breaks we have the expertise and resource to fix it within 24 hours".

Sometimes that's not enough -- sometimes you're risking tens of thousands of dollars and you want insurance against that. Sometimes, though, it *is* enough, and it's right to stop and make that decision.

But aren't you forgetting about this: http://www.mysql.com/news-and-events/news/article_ 968.html (Oracle buys the maker of Innobase - a popular backend to MySql)

If you aren't redistributing the python code, you don't need a license other than GPL for MySQL. The FLOSS exemption is for those who are distributing their applications with MySQL, not for web sites. For an example reply from MySQL saying so, see Licence for MySQL use at website?.

I agree, though; if you're not validating what your cookies are sending you in some way, you do likely have larger problems.

Then explain why MySql released the FLOSS exception list?

All MySql Client libraries for C, Python, PHP are licensed under the GPL, making any closed-source website application using these libraries unpossible, right?

I've been trying to research this annoying license issues for a python-based website

You cite a couple very narrow scenarios in your post. Major investment banks and SAP installations. As far as SAP they released MaxDB which is what they base SAP on. MaxDB and MySQL are very closely related. As far as investment banks I don't know enough about what they use. And they probably wouldn't reveal that anyway. However it is used by a lot of high traffic sites as the MySQL website clearly documents: http://www.mysql.com/why-mysql/case-studies/ The organization I work for runs MSSQL Oracle and MySQL. Guess what database is used as the core of our business and would cause the most impact if it was unavilable? MySQL. Guess which database has given us the most problems in the terms of deployment/configuration/crashes? Oracle. Guess which database hasn't had any issue (at least that I know of) MSSQL. Kind of opposite of what you would expect huh? :)

I think you're misinterpreting the MySQL license, which is the GPL, as interpreted by MySQL AB. Whether or not eldavojohn's site is built on open-source software is irrelevant because he's not distributing the software. He's only distributing HTML files, so he's under no obligation to purchase a license for MySQL. In fact, the link above specifically exempts eldavojohn from having to release any code:

Free use for those who never copy, modify or distribute. As long as you never distribute the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not.

This is sometimes called the the "Application Service Provider" loophole in the GPL (since MySQL specifically mentions that the GPL doesn't apply in this case, it's not a loophole, but some people call it one anyway). ASPs don't have to publish their modifications to GPLed code, because they don't distribute the code. They only distribute the "output" of the code, which is not protected by the GPL.

• 
  
• If your software is licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, then use our GPL licensed version.
• If you distribute a proprietary application in any way, and you are not licensing and distributing your source code under GPL, you need to purchase a commercial license of MySQL
• If you are unsure, we recommend that you buy our cost effective commercial licenses. That is the safest solution. Licensing questions can submitted online for our advice, and we encourage you to refer to the Free Software Foundation or a lawyer as appropriate.

I can't really quote performance stats; I've never dealt with a server that gets enough traffic to make a difference.

What I can tell you is that there is a major, important consequence to using MySQL for Windows rather than *nix. It stems from the way MySQL stores table data: the name of the table is the filename of the file used to store that table. Ditto for database names.

On Windows, filenames are case insensitive. The filename "MySQL" is the same as "mysql" is the same as "MysqL", etc. Consequently, table and database names on MySQL windows servers are case insensitive. Case is preserved on *nix, because filenames are case sensitive.

That's not to say that you shouldn't use MySQL for Windows, just be prepared for portability issues if you happen to migrate from *nix.

MySQL documentation on the subject

Our aim is to support the full ANSI/ISO SQL standard, but without making concessions to speed and quality of the code.

Our aim is to support the full ANSI/ISO SQL standard, but without making concessions to speed and quality of the code.

http://dev.mysql.com/doc/refman/5.0/en/innodb-fore ign-key-constraints.html

Yeah AV *is* an extra cost. You're right there. You shouldn't have to update them manually though. Any good corporate AV solution will have systems for managing and reporting on AV deployments.

WSUS is a free tool from Microsoft for managing the testing and deployment of hotfixes.

Log files (IMO, the number one annoyance with windows systems) can be managed with scripts by using scheduled tasks, as can other mundane tasks like defragmenting. For Windows 2000 and NT4 which don't come with command line defragmentors there are free tools avaialable that will do the job. Email reports can be sent via email by piping (c:\maintenance.cmd >> c:\daily_report.txt) the output of your scripts to a textfile and using freely available command-line mailer tools to send them.

Security and other logs can be dumped to a freely available database automatically using freely avaiable tools.

One very valid complaint is that Windows doesn't come with these tools by default. Once you get everything together though, life becomes much easier.

I won't argue with you that UNIX is easier. An OpenBSD/Postfix box I set up about two years ago has not required a security patch yet, and if not for power outages and physical moves, would have two years of uptime right about now.

MySQL claims that using MySQL via ODBC means you need to either abide by GPL or use a commercial license for MySQL (which I find questionable, but okay) but what I was talking about was the GPL "infecting" client software, not finalized solutions. It does *not* mean that any software anywhere that uses ODBC must be GPL because you might use it with MySQL.

Their legal principle is distribution rights of their software, not "derived works" rights over your software. Your are correct that the net-effect is the same, but the argument is quite different.

Untrue. The legal principle is use of the software, which is creating derived works (the only use for a library). Otherwise, for example, you could freely write programs using commercial third party libraries provided you didn't distribute them, which is not true.

Note that writing to an ODBC interface, and your clients using MySQL via it's (GPL) ODBC driver, does *not* require you to abide by the GPL.

MySQL disagrees and claims the "viral" nature crosses the system ODBC or JDBC boundry:
http://www.mysql.com/company/legal/licensing/comme rcial-license.html

Plus your disagreement with MySQL defeats the claim that "If you make a 5 minute research at the FSF web page you'll know more than enogh"...

> many commercial library vendors and they absolutely claim rights over your finished product - many of them require royalties

Their legal principle is distribution rights of their software, not "derived works" rights over your software. Your are correct that the net-effect is the same, but the argument is quite different.

You would be surprised by the number of developers that I know that developed their apps using MySQL and then had to pay for the comercial license many months later because they didn't read the fine print.

MySQL Products are available under the "dual licensing" model. Under this model, users may choose to use MySQL products under the free software/open source GNU General Public License (commonly known as the "GPL") or under a commercial license. ISVs and Resellers, who are embedding and reselling MySQL as part of their own commercial solutions, can purchase a MySQL commercial license.

The MySQL libraries are not exclusively GPL licensed, so it's not mandatory that an application using them be GPL licensed. A list of 20 other open source licenses which are accepted by MySQL for use with its client libraries can be found at http://www.mysql.com/company/legal/licensing/foss- exception.html . The PHP license is one of them.

The MySQL client libraries are under the GPL, not the LGPL.

MySQL even claim that if you implement your own client, it speaks the MySQL protocol, and as such is a derivative work of the MySQL server and so must be made available under the GPL.

If you want to use it from something like Perl/PHP whatever, you will find the license cost is zero. If you want to incorporate it as part of an in-house system, there is no issue. It is only if you want to build non-GPL software for distribution. OTOH, you will find that many commercial users have no issues with paying for support. Although not as full featured as Oracle 10g, it costs a tad less.

If you want to use it from something like Perl/PHP whatever, you will find the license cost is zero. If you want to incorporate it as part of an in-house system, there is no issue. It is only if you want to build non-GPL software for distribution. OTOH, you will find that many commercial users have no issues with paying for support. Although not as full featured as Oracle 10g, it costs a tad less.

The summary you quoted said that "Pricing/booking" is done by the MySQL servers. You don't think telling people the prices and letting the people book their trips is mission-critical? It seems unlikely that they would earn much money if they didn't let anyone make bookings and get those credit card numbers from them.

What Sabre said about MySQL is "To provide the best possible service requires maintaining a massive database that can meet extreme performance demands, with very high reliability. The MySQL database has easily met these needs, and for a low total cost of ownership" and "We benchmarked our application on several databases, including open source, commercial and a specialized in-memory relational database, and MySQL was the best performing database". From http://www.mysql.com/news-and-events/press-release /release_2003_33.html

When it comest to AdWords, an "unmitigated disaster" that even "heroic performance tuning" couldn't save, even after rewriting every query for it, followed by reverting to the better-performing MySQL solution, is not what I'd call a resounding success story for a migration to a purely commercial database. Zack has some useful quotes and other links at http://zurlocker.typepad.com/theopenforce/2005/12/ googles_use_of_.html (he's MySQL's VP of Marketing).

Notice the consistency here: for both Sabre and Google, MySQL was the best performing solution, not the databases they compared it to.

One manager tried going from MySQL to commercial and had a disaster, even after rewriting everything, while the other went from commercial to MySQL and saved their company millions of dollars in TCO while delivering a world-class solution. I know which manager I'd rather be! :)

I've done the multiple database support routine myself. Best to know the databases you're going to support in advance. Standards might as well not exist when you go for maximum efficiency. Fortunately I generally didn't need maximum efficiency and the worst I generally had to deal with was Oracle limitations compared to Sybase and Microsoft SQL Server.

Even with the success stories here, there really are some cases where MySQL doesn't provide the best business case - but it's getting harder and harder to find them. There always will be some, though.

Fully integrated with MySQL Server, the InnoDB storage engine
maintains its own buffer pool for caching data and indexes in main memory.
InnoDB stores its tables and indexes in a tablespace, which may consist of
several files (or raw disk partitions). This is different from, for
example, MyISAM tables where each table is stored using separate files. InnoDB
tables can be of any size even on operating systems where file size is limited
to 2GB.

well, this is their own list, but hey, it has some names...
http://www.mysql.com/why-mysql/case-studies/

then there's this story ;)
http://xooglers.blogspot.com/2005/12/lets-get-real -database.html

hoping that "you get what you pay for" will get a swarm of professional bloodsuckers that will make sure to sell you the most expensive plan, even you could get the same quality for much less.

and, adiitionally, i don't hear much "you can trust big systems to ms products" nowadays ;)
usually stories are quite opposite...

Read more about MySQL licensing.

> you may want to look at the mysql website again, the remaining differences between their ANSI
> compliant mode and the standard seem like slim pickings for a critic.

Yeah, they're covering their butts in the documentation much better than the old days in which they blatantly stated that transactions and pk/fk constraints were bad. Now, it's much harder to find the things that they are embarressed about - like their old licensing faq, or compatibility issues. The url you provided only shows those compatibility problems that they have worked out. It does not list the existing ones for which there is no good solution. And I'm not in the mood to go through their documentation to find it all.

> Also, partitioning has been in there forever

Well, there's this: http://dev.mysql.com/doc/refman/5.0/en/partitionin g.html

Which says only:
"Chapter 15. MySQL Partitioning
This is the beginning of the Partitioning chapter. "

Maybe you're thinking of their separate clustering product? Which being limited to your available memory, isn't really the samething. Partitioning splits your data by either hash key or ranges into multiple physical tables. These tables are kept on either the same server (range partitioning via oracle, mdc via db2) or on multiple servers (hash partitioning via db2, think beowulf). In either case your application is unaware, the database handles the details. You just get speed. MySQL doesn't do this.

> as has memory tuning.

Not really. And keeping in mind that memory tuning is one of the most critical features of a database - one that allows you to eke out the maximum benefit from your expensive hardware...

The mysql documentation barely mentions memory tuning at all. It does give you a large set of pools, heaps, etc to tweak (about 28):
- http://dev.mysql.com/doc/refman/5.0/en/server-para meters.html

But this looks more like a haphazzard collection that has grown over time, rather than anything methodical. I couldn't actually find any recommendations for how to tune these in the documentation. Maybe it was hidden somewhere, but searches on 'memory' didn't turn it up. Moreover:

1. it fails to give you the flexibility you need: it appears to still be impossible to set up multiple buffer pools for read caching that are shared between sets of like tables. This is typically the *first* thing you should plan & tune. It allows you to ensure that some large tables get 99.9% of their hits from cache rather than memory - without having to move them into the memory storage engine in mysql - which you may not have sufficient memory to do.

2. it inefficiently uses memory: buffers can't be dedicated to a functional purpose, they often have to be dedicated to a storage engine. This means that if you are using both innodb & myisam you will pay a penalty in your memory usage.

MySQL does offer a lot of knobs to twist - really as many as db2 or oracle. It just doesn't seem to document what they do or how to analyze their result. And they aren't well thought out or complete, they're bizarre. Maybe duct-table and bailing wire to catch problems like:

"Note that if you use any other option to ALTER TABLE than RENAME, MySQL always creates a
temporary table, even if the data wouldn't strictly need to be copied (such as when you change the
name of a column). For MyISAM tables, you can speed up the index re-creation operation (which is the
slowest part of the alteration process) by setting the myisam_sort_buffer_size
system variable to a high value."

Here you can see that mysql has some mysterious problem doing ALTER TABLE - in which i

> you may want to look at the mysql website again, the remaining differences between their ANSI
> compliant mode and the standard seem like slim pickings for a critic.

Yeah, they're covering their butts in the documentation much better than the old days in which they blatantly stated that transactions and pk/fk constraints were bad. Now, it's much harder to find the things that they are embarressed about - like their old licensing faq, or compatibility issues. The url you provided only shows those compatibility problems that they have worked out. It does not list the existing ones for which there is no good solution. And I'm not in the mood to go through their documentation to find it all.

> Also, partitioning has been in there forever

Well, there's this: http://dev.mysql.com/doc/refman/5.0/en/partitionin g.html

Which says only:
"Chapter 15. MySQL Partitioning
This is the beginning of the Partitioning chapter. "

Maybe you're thinking of their separate clustering product? Which being limited to your available memory, isn't really the samething. Partitioning splits your data by either hash key or ranges into multiple physical tables. These tables are kept on either the same server (range partitioning via oracle, mdc via db2) or on multiple servers (hash partitioning via db2, think beowulf). In either case your application is unaware, the database handles the details. You just get speed. MySQL doesn't do this.

> as has memory tuning.

Not really. And keeping in mind that memory tuning is one of the most critical features of a database - one that allows you to eke out the maximum benefit from your expensive hardware...

The mysql documentation barely mentions memory tuning at all. It does give you a large set of pools, heaps, etc to tweak (about 28):
- http://dev.mysql.com/doc/refman/5.0/en/server-para meters.html

But this looks more like a haphazzard collection that has grown over time, rather than anything methodical. I couldn't actually find any recommendations for how to tune these in the documentation. Maybe it was hidden somewhere, but searches on 'memory' didn't turn it up. Moreover:

1. it fails to give you the flexibility you need: it appears to still be impossible to set up multiple buffer pools for read caching that are shared between sets of like tables. This is typically the *first* thing you should plan & tune. It allows you to ensure that some large tables get 99.9% of their hits from cache rather than memory - without having to move them into the memory storage engine in mysql - which you may not have sufficient memory to do.

2. it inefficiently uses memory: buffers can't be dedicated to a functional purpose, they often have to be dedicated to a storage engine. This means that if you are using both innodb & myisam you will pay a penalty in your memory usage.

MySQL does offer a lot of knobs to twist - really as many as db2 or oracle. It just doesn't seem to document what they do or how to analyze their result. And they aren't well thought out or complete, they're bizarre. Maybe duct-table and bailing wire to catch problems like:

"Note that if you use any other option to ALTER TABLE than RENAME, MySQL always creates a
temporary table, even if the data wouldn't strictly need to be copied (such as when you change the
name of a column). For MyISAM tables, you can speed up the index re-creation operation (which is the
slowest part of the alteration process) by setting the myisam_sort_buffer_size
system variable to a high value."

Here you can see that mysql has some mysterious problem doing ALTER TABLE - in which i

Also, partitioning has been in there forever as has memory tuning.

I frequently do approximately what you are talking about and MySQL returns almost instantly. The main problem I have is latency, which may be in my network but I think is more likely in the server.

this is why mysql is a joke

http://dev.mysql.com/doc/refman/5.0/en/constraint- invalid-data.html

" Before MySQL 5.0.2, MySQL is forgiving of illegal or improper data values and coerces them to legal values for data entry. In MySQL 5.0.2 and up, that remains the default behavior, but you can select more traditional treatment of bad values such that the server rejects them and aborts the statement in which they occur. This section describes the default (forgiving) behavior of MySQL, as well as the newer strict SQL mode and how it differs."

" MySQL allows you to store certain incorrect date values into DATE and DATETIME columns (such as '2000-02-31' or '2000-02-00'). The idea is that it's not the job of the SQL server to validate dates. If MySQL can store a date value and retrieve exactly the same value, MySQL stores it as given. If the date is totally wrong (outside the server's ability to store it), the special date value '0000-00-00' is stored in the column instead."

This is still a hobbiest toy.

Sorry, but when MySQL developers tell me things like "count (*) is supposed to give you an estimate"

To be fair to MySQL, that's only for tables of type InnoDB. MyISAM and other storage engines do return an accurate count. From here:

InnoDB does not keep an internal count of rows in a table. (This would actually be somewhat complicated because of multi-versioning.) To process a SELECT COUNT(*) FROM t statement, InnoDB must scan an index of the table, which takes some time if the index is not entirely in the buffer pool. To get a fast count, you have to use a counter table you create yourself and let your application update it according to the inserts and deletes it does. If your table does not change often, using the MySQL query cache is a good solution. SHOW TABLE STATUS also can be used if an approximate row count is sufficient.

It should be noted, though, that you have to use InnoDB tables for all those "modern" database features like transactional support* and foreign key constraints.

It may be a bit of a bother, but it's not that hard to create the "counter table" for whatever it is you need to count. All the major DBs have something that's a pain in the ass...at least with MySQL you didn't have to pay for the pain.

*BDB and NDB Cluster are apparently transaction safe as well, but I have no experience with them; and for whatever reason, they don't seem to be popularly used.

When I read your comment, I thought you were joking (I don't follow the MySQL scene at all). A quick google pulled up this link and sure enough, what you posted is true. The worst part about this is that the status is 'Not a bug'. Huh? Even if this is over a year old, and even if this isn't in the current release, and even if anything, how could anyone think this isn't a bug?

I think your comment is especially true when it comes to PHP and MySQL. The websites for PHP and MySQL have a massive amount of information and documentation which could replace several books written for them already. The comments in their documentation on the two websites posted by users is even more useful:

MySQL documentation
PHP documentation

So what you're saying is... Don't use MySQL.

I'm not sure what you're talking about.

MySQL 5.0 was released for production use in October. Some of the less well-known additions in version 5.0 include increased standards compliance in joins and an INFORMATION_SCHEMA database for accessing DB and schema metadata.

MySQL has supported transactions via InnoDB and BDB for several years. Further additions scheduled for 5.1 and 5.2 will make it even easier to use storage engine supporting transactions or whatever other features you care about.

BTW, MySQL now employs several Software Architects (and others) who are *extremely* well versed in SQL 99 and SQL:2003, as well as implementations in other widely used RDBMS such as Oracle, DB2, Sybase, Postgres, and SQL Server. They are tasked with giving developers (and the rest of us who work there) an extremely hard time when something doesn't support the SQL specs, and so they do. :)

MySQL 5.0 is not your father's MySQL, and 5.1+ will be even less so.

Stay tuned for further developments, and check out the MySQL 5.1 Manual-in-progress for a preview of what's to come.

Of course it's never the fault of the programmer. From the description of PASSWORD() from the MySQL docs:

"Calculates and returns a password string from the plaintext password str, or NULL if the argument was NULL. This is the function that is used for encrypting MySQL passwords for storage in the Password column of the user grant table.

Note: The PASSWORD() function is used by the authentication system in MySQL Server; you should not use it in your own applications. For that purpose, use MD5() or SHA1() instead. Also see RFC 2195 for more information about handling passwords and authentication securely in your applications."

This has been in the docs for years, long before 4.1 (the version in which the internal hash algorithm was updated) was released. The possibility for application breakage from this change was also fully documented in the upgrade release notes. In fact, it's mentioned in the first real step. As if that wasn't enough, you actually have to want to use the new password algorithm. If after you upgrade the grants table isn't manually altered to support the new hash length, the PASSWORD() function works exactly as it did in versions 4.0 and earlier.

Maybe you should have spent the 3 hours on reading the docs, because one of the features of MySQL (prior to 4.1) is that the FIRST timestamp column of any record is automatically updated to the current date/time whenever you change (insert/update/replace) a record. This default behaviour has changed since MySQL 4.1, now you can specify if you still wish to use this behaviour or not, or if you want another TIMESTAMP to change : http://dev.mysql.com/doc/refman/5.0/en/timestamp-4 -1.html

I ran into an annoying situation just yesterday trying to modify some code that 'depended' on mysql. I wanted to know WHEN a record was made in a certain table..

Quick and dirty solution was to add a column with the default value of CURRENT_DATE().. Too bad that didn't work. There is even an entry in the mysql bug database about it that date back years..

http://bugs.mysql.com/bug.php?id=1696
http://bugs.mysql.com/bug.php?id=2040

More retarded is that the lovely people on the mysql dev team have those classified as 'feature requests'.. Its not a feature request, its just another fundamental aspect of mysql that is missing and the type of attitude the mysql team has for missing features is just laughable(anyone remember reading the old mysql docs that talk about how useless transactions are and that you would never need them?)

I had to spend 3 hours(no joke) dissecting the code to have it insert the current date into the record I wanted, 3 hours I will never get back.

Thats just typical of every encounter I have had with mysql.. some annoying stupid feature I take for granted just isn't there.

I ran into an annoying situation just yesterday trying to modify some code that 'depended' on mysql. I wanted to know WHEN a record was made in a certain table..

Quick and dirty solution was to add a column with the default value of CURRENT_DATE().. Too bad that didn't work. There is even an entry in the mysql bug database about it that date back years..

http://bugs.mysql.com/bug.php?id=1696
http://bugs.mysql.com/bug.php?id=2040

More retarded is that the lovely people on the mysql dev team have those classified as 'feature requests'.. Its not a feature request, its just another fundamental aspect of mysql that is missing and the type of attitude the mysql team has for missing features is just laughable(anyone remember reading the old mysql docs that talk about how useless transactions are and that you would never need them?)

I had to spend 3 hours(no joke) dissecting the code to have it insert the current date into the record I wanted, 3 hours I will never get back.

Thats just typical of every encounter I have had with mysql.. some annoying stupid feature I take for granted just isn't there.

Does anyone know the practical difference in using other storage engines? For example, how does using Berkeley DB (http://dev.mysql.com/doc/refman/5.0/en/bdb-storag e-engine.html) compare?

Also, how typical are non-InnoDB configurations of MySQL?