Since we are currently speaking a lot about new ideas, maybe there is one.

MySQL provides a lot of Live Web Seminars being offered as On-Demand Webinars a few days later. This is a great offer - it provides presentations from experts that everybody can join in and watch or download as soon as they are provided on the On-Demand Webinar pages - all for free.

During the Users Conference, there were some "HackFests" where developers showed how to extend functionality in code right in front of the attendees.

Maybe this could be combined with Webinars? There are many topics that can be …

Hey, that's a great topic and I very much like Zack's article and the responses (thanks Roland, Mats ... did I forget someone?).

Some time before I joined MySQL I worked for a local company (which is the biggest company in the region where I live) and I could perfectly see how it should not be. There were (and still are) very strong hierachies and if you are in the low areas of the hierachy structure, the management only wanted you to "work on something". The last thing they wanted was that employees speak up and shake on the structures of the company. No criticism was appreciated, employees should just do their daily work and even if they do …

One little known fact about MySQL Indexing, however very important for successfull MySQL Performance Optimization is understanding when exactly MySQL is going to use index and how it is going to do them.

So if you have table people with KEY(age,zip) and you will run query something like
SELECT name FROM people WHERE age BETWEEN 18 AND 20 AND zip IN (12345,12346, 12347) do you think it will use index effectively ? In theory it could - it could look at each of the ages from the range and look at all zip codes supplied. In practice - it will not:

PLAIN TEXT SQL:

1. mysql> EXPLAIN SELECT  name FROM people WHERE age BETWEEN 18 AND 20 AND zip IN (12345,12346, 12347);
2. +----+-------------+--------+-------+---------------+------+---------+------+-------+-------------+
3. | id | select_type | TABLE  | type  | …

Reading Zack Urlocker's and Mat Kindal's posts on how good ideas are killed, some more ways came to my mind:

How do you expect this to develop in the future?

A great downer for bold and new ideas is to ask how it will develop in the future. Although it's reasonable to probe for it, a future perspective should always be seen as a possible scenario at best, and not be used as lakmus test for the entire idea.

Of course, it's different for things that have been done a thousand times before. In such cases, it's reasonable to extrapolate and to assume that what happened in a similar case is like to apply here again.

Hey, that's a great idea, that's …

Again, I cannot help but follow up on Zack's post on How to Come Up With Ideas. In the modern days of hypercompetition, where today's state-of-the-art solution quickly become yesterdays news, you have to set an environment where you continuously come up with new ideas and new solutions. Creating such an environment is not an easy task, since people are... well, people.

With this in mind, I find especially Zack's first five points critical, but I would like to add two more items that I personally feel are missing.

1. Set an example

   When working as a doctoral student it was mandatory for all researchers to attend research seminars given by visiting fellows. The department's head professor always attended …

Some of you have already noticed my shift, I joined the MySQL AB professional services department full-time as a Support Engineer. Since I started at MySQL in 2001 I already did training part-time in the Australia and New Zealand region (next to my Documentation job, back then). And ye, I'll still be at some conferences, particularly in Australia.

So, Arjen in Support. It's great to get my hands dirty again (with things other than tricky licensing questions ;-). Support, by the way, is like the insurance you wish you'd taken out when your house is on fire.

MySQL's support offering is part of MySQL Network, our subscription service with a very simple per-server/per-year pricing model: we don't care about funny stuff like cores or database size.
It's available from USD 595 per server (Basic), up to USD 4995 per server (Platinum) where you get 24x7 support …

Every so often I find companies who I think get it. A couple of days ago while researching Amazon's S3 technology I came across the company JungleDisk.

What do they do? They wrap a backup service/webdisk around Amazon's S3 service. Amazon provides the disk storage, and Jungle Disk provides an interface. I would suspect that Jungle Disk is no more then a garage setup for a company (much like all of the book resellers I see making money off selling used books on the site). I've been considering buying a .MAC account since I am a bit paranoid about backups, but at the price per gig, JungleDisk would make a lot more sense.

This is not the only S3 project/business I have found. I had been watching the work …

OK! So, the new mysqlcamp.org website and wiki is now up and running. Many thanks go out to the guys at PeanutButter Wiki, who graciously allowed us an enterprise edition version of pbwiki so that we could use the mysqlcamp.org website unhindered. You guys rock!

Also, many more thanks to Kevin Burton, the CEO of Tailrank, for his help over the last week in contacting pbwiki and helping with some setup. As you can see on the wiki, we've got a few sponsors already, and things look pretty good to make this a fantastic inaugural MySQL camp. We're aiming for around 100 developers and users, with a …

One of my colleagues recently redesigned a system for scheduling work, and needed to write a multiple-table UPDATE with ORDER BY and LIMIT, neither of which is supported for multiple-table UPDATE in MySQL. This article explains how to do it anyway, and shows how to rewrite a first attempt for hundreds of times better performance. Introduction Without revealing too much about my employer’s internal systems, I want to give a little bit of context.

I’ve released another version of the innotop MySQL and InnoDB monitor. It’s worth upgrading to this version not only because of the new features, but also because it should handle more special cases without crashing. Of course, if it does crash, I appreciate your help fixing it; see this article about what information I need. Changes since version 0.1.123 include: Fixes to deal with older versions of Perl. Thanks to everyone who helped me find out what was wrong.