After seeing quite some SQL statements over the years, something is bugging me: there is no consistent convention as for how to write an SQL query.
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 after 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.
PlanetMySQL Voting: Vote UP / Vote DOWN
