I’ve been writing SQL on both Oracle and SQL Server for 13 years, and never really found myself getting frustrated at the way the language was put together. So when I started teaching it 2 years ago, I was instinctively defensive when some of the delegates suggested that the way SQL did things was not necessarily the best way. But having taught the course maybe 30 times now, some things just keep on coming up, so and they’re getting impossible for me to ignore. So I do now have a little wish list of changes that I would like to make to the SQL language to make it easier to use and learn. I will try to only suggest changes that would not require any rewriting of previous code.
1. Allow the FROM clause to come first in the SELECT statement
This is a constant suggestion from the delegates on the course. It gets mentioned almost every time. They don’t understand how we can start specifying which columns we want to see before we’ve said which tables they’re in. They especially don’t understand how we can start using a table alias before we’ve declared it. The database looks at the FROM clause first for this very reason, and I’ve now started suggesting to the delegates that whenever they come across a SELECT statement they should look at the FROM clause first too. Wouldn’t it be much easier if SQL would just let us write it that way? Or in fact….
2. Allow the clauses of a SELECT statement to be written in any order.
May sound radical, but why not? Each clause does its own job in the SELECT statement, more or less independently of any other, so why should the order of clauses make a difference?
FROM customers
SELECT name, email_address
ORDER BY name
WHERE city = 'LONDON';
As I already said, the database doesn’t read a SELECT statement from top to bottom anyway, so why shouldn’t we be able to change the order around?
3. Don’t have UNIONs filter out duplicates by default
Okay so this is not possible because it would mean rewriting existing code, but I so wish that the UNION keyword brought back all results including duplicates, with UNION DISTINCT for if you wanted the duplicates removed.
4. Inferred GROUP BY clauses
If my SELECT clause is SELECT office_name, COUNT(*) it would be great if I could miss out the GROUP BY clause and have it inferred as GROUP BY office_name.
5. Allow conditions involving aggregate functions in the WHERE clause
Any condition involving an aggregate function (MIN, MAX, SUM, COUNT etc) has to go in a HAVING clause. This is because the database evaluates the WHERE clause before the aggregation and the HAVING clause after. But it would be great if we could write it all in the WHERE clause and have the database work things out behind the scenes. (It already does this to a certain extent, e.g. rewriting id IN (1,2,3) to id = 1 OR id = 2 OR id = 3).
6. Allow the use of column aliases throughout the query
e.g. SELECT name, salary * 1.05 AS new_salary FROM staff WHERE new_salary > 50000;
Surely it wouldn’t be too much to ask, if it can’t find a column name in the tables in the FROM clause, just to check the SELECT clause for column aliases?
7. Use some common sense in joining conditions
The join condition after the ON keyword is used to specify how the data in 2 tables is related. In some cases this can be long and complex, but the vast majority times it is a simple equijoin. Where it finds a single equijoin, SQL should assume that we are referring to one column from each of the tables, and not require us to qualify ambiguous column names on one side of the join if the other side is unambiguous.
e.g. to join the tables customers (id, name, email) and orders (id, customer_id, order_date) I should be able to write
SELECT customer_name, order_date FROM customers JOIN orders ON customer_id = id
without having to qualify the id column. Yes it is ambiguously defined, but why on earth would I be referring to the id from the orders table? Since customer_id can only possibly come from orders it should assume that id is from customers.
8. Allow table joins in UPDATE and DELETE statements with a more simple syntax
I would like to be able to run
UPDATE staff s JOIN dept d ON s.dept_id = d.id
SET s.salary = s.salary * 1.05
WHERE d.dept_name = 'ICT';
Recent versions of the databases allow this logic but with the clunky FROM clause – I think the above is far simpler and more intuitive
9. Throw an error for = NULL and <> NULL in conditional expressions
The above will never produce any results, so why not simply throw an error if we mistakenly use these instead of IS NULL or IS NOT NULL? That will alert us to the error we’ve made – because it almost certainly will be an error. Or better still, why not just have SQL rewrite = NULL to IS NULL and <> NULL to IS NOT NULL? (I’m choosing to ignore the SQL Server ANSI_NULLS option abomination which is deprecated in future versions).
10. Oracle only: stop kidding us on about VARCHAR2
I joined Oracle in 1998 and was told to use the stupidly named VARCHAR2 instead of VARCHAR, because a new VARCHAR would be implemented soon. 13 years later no sign of it. It’s not going to come, is it? And because VARCHAR works anyway, as a synonym, loads of code would have to be rewritten if they ever do bring it out.
11. SQL Server only: have a TRUNC function for dates.
That’s it. Please. Just have a TRUNC function for dates.
Oh and also, bring in a new concatenation operator that implicitly converts numbers to strings. Thanks. UPDATE: Looks like both of these are effectively fixed in the next version of SQL Server (codename “Denali”). Thanks!
12. Allow ADD COLUMN syntax in ALTER TABLE
How come ALTER TABLE cities ADD country VARCHAR(20) works, but not ALTER TABLE cities ADD COLUMN country VARCHAR(20)? That is crazy, especially when you do need to specify the COLUMN keyword to drop a column.
13. Don’t allow UPDATE and DELETE on a view
Again this would need code to be rewritten, but I don’t know who had the idea to create something that you can update and then call it a “view”. What a bad choice of name. In fact on second thoughts the name is fine, but what a bad choice to have it allow UPDATE and DELETE.
Okay so I included a couple that would change existing behaviour, so they’re non-starters, but what do you think about the others? As far as I can think of, none of them would cause any problems or ambiguity? Can you think of any? Others to add to the list?
About the poster

Dean Bullen is Impartica’s SQL course leader and has been working with SQL since 1998. He previously worked for Oracle and has been working with SQL Server since 2006.