How much can a single consultant observe? I agree Oracle should not go to PR based on my experience. But I find that:

• More companies are now familiar with InnoDB than there used to.
• More companies are interested in migration to InnoDB than there used to.
• More companies feel such migration to be safe.
• More companies start up with an InnoDB based solution than with a MyISAM based solution.

This is the way I see it. No doubt, the Oracle/Sun deal made its impact. The fact that InnoDB is no longer a 3rd party; the fact Oracle invests in InnoDB and no other engine (Falcon is down, no real development on MyISAM); the fact InnoDB is to be the default engine: all these put companies at ease with migration.

I am happy with this change. I believe for most installations InnoDB provides with a clear advantage over MyISAM (though MyISAM has its uses), and this makes for more robust, correct and manageable MySQL instances; the kind that make a DBA’s life easier and quieter. And it is easier to make customers see the advantages.

I am not inclined to say “You should migrate your entire database to InnoDB”. I don’t do that a lot. But recently, more customers approach and say “We were thinking about migrating our entire database to InnoDB, what do you think?”. What a change of approach.

And, yes: there are still a lot of companies using MyISAM based databases, who still live happily.

If I were to develop some open source project, and a bug report came which only applied to MySQL 5.0.51 (but more recent versions worked fine), would I need to fix the code so as to support this older version?

How about supporting 5.0.22 (released almost 4 years ago, with almost 70 revisions since)? Would you expect an open source project to support this MySQL version because, say, this is the default version in your yum repository?

I would like to concentrate on the currently stable MySQL versions: 5.0 and 5.1. Versions 4.x are out of the question for me, and 5.5 is not yet GA.

Sure, it would be great to support everything. But also time and effort consuming. So, I would greatly appreciate your feedback!

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

I’m going to leave formatting, upper/lower-case issues aside, and discuss a small part of the SQL syntax: table aliases. Looking at three different queries, I will describe what I find to be problematic table alias use.

Using the sakila database, take a look at the following queries:

Query #1

SELECT
 R.rental_date, C.customer_id, C.first_name, C.last_name
FROM
 rental R
 JOIN customer C USING (customer_id)
WHERE
 R.rental_date >= DATE('2005-10-01')
 AND C.store_id=1;

The above looks for film rentals done in a specific store (store #1), as of Oct. 1st, 2005.

Query #2

SELECT
 F.title, C.name
FROM
 film AS F
 JOIN film_category AS S ON (F.film_id = S.film_id)
 JOIN category AS C ON (S.category_id = C.category_id)
WHERE F.length > 180;

The above lists the title and category for all films longer than three hours.

Query #3

SELECT c.customer_id, c.last_name
FROM
  customer c
  INNER JOIN address a ON (c.address_id = a.address_id)
  INNER JOIN (
    SELECT
      c.city_id
    FROM
      city AS c
      JOIN country s ON (c.country_id = s.country_id)
    WHERE
      s.country LIKE 'F%'
  ) s1 USING (city_id)
WHERE
  create_date >= DATE('2005-10-01');

The above lists customers created as of Oct. 1st, 2005, and who live in countries starting with an ‘F’. The query could be solved without a subquery, but there’s a good reason why I made it so.

The problems

I used very different conventions on any one of the queries, and sometimes within each query. And it’s common that I see the same on a customer’s site, what with having many programmers do the SQL coding. Again, I will only discuss the table aliases conventions. I’ll leaver the rest to the reader.

Here’s where I see problems:

• Query #1: In itself, it looks fine. Rental turns to R, Customer turns to C. I will comment on this slightly later on when I provide my full opinion.
• Query #2: So film turns to F, category turns to C. What should film_category turn into? Out of letters? Let’s just go for S, shall we? But S has nothing do with film_category. Yet it’s so commonly seen.
• Query #2: We’re using the AS keyword now. We didn’t use it before.
• Queries #1, #2: Hold on. Wasn’t C taken for customer in Query #1? Now, in Query #2 it stands for category? I’m beginning to get confused.
• Query #3: Now aliases are lower case; I was just getting used to them being upper case.
• Query #3: But, hey, c is back to customer!
• Query #3: Or, is it? Take a look at the subquery. Theres another c in there! This time it’s city! And it’s perfectly valid syntax. We actually have two identical aliases in the same query.
• Query #3: If I could, I would name country with c as well. But I can’t. So why not throw in s again?
• Query #3: and now I don’t even bother using the alias when accessing the create_date. Well, there’s no such column in any of the other tables!

Proper conventions

What I find so disturbing is that whenever I read a complex query, I need to go back and forth, back and forth between table aliases (found everywhere in the query) and their declaration point. Such irregularities make the queries difficult to read.

Any of the above issues could be justified. But I wish to make some suggestions:

• Decide whether you’re going for upper or lower case.
• Do not use the same alias twice in your query, even if it’s valid.
• Aliases do not have to be single character. film_category may just as well be FC.
• Do not alias something that is hard to interpret. s does not stand for country.
• Think ahead: use same aliases throughout all your queries, as far as you can. If uniqueness is a problem, make for longer aliases. Use cust instead of c.

The above should make for more organized and readable SQL code. Remember: what one programmer finds as a very intuitive alias, is unintuitive to another!

My own convention

Simple: I only use aliases when using self joins. I am aware that queries are much longer what with long table names. I go farther than that: I prefer fully qualifying questionable columns throughout the query. Yes, it makes the query even longer.

I know this does not appeal to many. But there’s no confusion. And it’s easily searchable. And it’s consistent. And if properly formatted, as in the above queries, is well readable.

Now please join me in asking Oracle if they can add multi-line Strings for java, as there are for python.

I’m under the assumption that no shocking news are delivered. That is, that for the near future, it’s business as usual for MySQL.

Last year’s great message, delivered by Karen Padir, was “more community”. More community participation, more community patches. Looking back, I’m not sure I saw that coming true. The 5.4 version was announced at that same conference, and was criticized for being community-oriented yet community-hidden. The latest 5.5 milestones announcement took everyone by surprise again. Ideas from Google patches were incorporated into 5.5M2. but, to the best of my understanding, no community patch was delievered.

I have both congratulated and expressed my desire that community took greater part in this.

So what am I looking forward to hear?

1. Like everyone else, the general plans Oracle holds for MySQL. Again, I’m not expecting shocking news here.
2. The expected roadmap for MySQL, technically speaking. I don’t actually know if there is a roadmap right now.
3. The intended role for the MySQL community. Frankly, it would be just fine with me if Oracle were to say: “we will not accept community patches”, and that would be the end of it. That’s fine, because it’s their right, and it would be an honest announcement. Naturally, I’ll be much happier to hear “we will incorporate the best 20 community patches withing the next three days”. Somewhere in between, I’ll be really satisfied with a clear explanation of how Oracle sees the community, and how it would like to cooperate with it. Will it share the development plan with the community? Will it allow the community to have a say about what goes in or not?

I realize this must all be very pressing, what with the acquisition; big new company; new rules; new bosses; new things to learn. But I do believe it’s in Oracle’s best interest (and obligation) to speak up their mind on MySQL in relation to the community.

The situation where the users (not the community) don’t know what’s planned for MySQL on the technical level, what’s the next milestone, when the 5.4/5.5 versions are scheduled to be released, what will happen with all those features which were supposed to be incorporated into 5.2/6.0 — had better be done with quickly.

My congratulations to the MySQL team on the finalization of the acquisition, and best wishes to a smooth and successful merge into Oracle.

The advantages I find in this model are in particular beneficial for MySQL. What I find good about this model are:

• Things are unstable for shorter periods. Even if some feature is not full stable in some milestone, the model encourages that such a feature is fixed on higher priority.
• It is easy to create a priority ranking for new features. Moreover, priorities are expressed more by chronological time of development, less by “how many people are working on it”.
• The model pushes towards rapid development, since you can’t release M5 before M4 is complete.

The last versions of MySQL took long time to complete. Take 5.1, for example: partitioning and event scheduling were long considered GA before row-based replication was half stable. Consider the so small but useful sub-second slow logs; the variables made dynamic in 5.1 (slow log again, for example); the new INFORMATION_SCHEMA tables.

Most of these took very little time to develop and stabilize, but had to wait extra couple of years till the entire version was evetually released.

There is a matter of stability question. Is M3 stable? Is M2?

Smaller, successive changes make for stabilized milestones; but this is vague: 5.5 is based on 5.4, in itself BETA. So is any 5.5 milestone stable?

Such issues need to be resolved. Like everything else in life, this model can be abused to no good, or can be properly implemented to make good success.

I’m glad to see google patches making it into the mainstream; I would love to see more community work merging in. I would love to have the community have a say about what should go into the next milestones.

But what I’ve just recalled was a discussion (was it previous year, or the one before that?) comparing the “PostgreSQL Conference” and the “MySQL Users Conference”, as it was named back then. In that discussion, the PostgreSQL people were bashing MySQL, saying that the “PostgreSQL Conference” was all about the database and whatever was around it, whilst the “MySQL Users Conference” clearly stated that the attendees were “just users”, not like real participants or members.

As I recall, it was a heat debate (and I apologize for not linking). I thought it was just semantics.

Anyway, here we are at 2009, there is no “Users”, it’s just like in PostgreSQL, and I still think it’s just semantics.

I think a name can mean whatever you want it to mean. It’s best to judge by actions, which is an altogether different thing.

I do not hold a position this way or the other.

This concludes my postings with regard to the MySQL (Users?) Conference & Expo 2009, which were non-technical. I’ll keep to technical stuff in the future, I promise. I enjoyed the conference very much, a big applaude to the presenters and the organizers, and to the many friendly people who attended!