Problems of SQL
- There is just no real standard. Every product has a little bit
different syntax rules, even for quite simple things. This is not obvious
for beginners, but leads to vendor lock-in later in the development cycle.
- Too many syntax rules. Hard to learn, hard to extend. In 'regular'
programming languages, the syntax rules don't change that often when
a feature is added (for example, when a method is added).
- Data types are not portable amoung database products.
- Size restrictions in data types seems to be not modern. There is
no maximum size for Java Strings, and most people don't complain about
that. Some developers (or is it project leaders?) often set the maximum
size of a VARCHAR column too low at the beginning, and changing it later
is a waste of time.
- No standard for autoincrement columns / sequences.
- No Unicode support.
- NULL is not equal to NULL. This is a major headache for many queries,
for example where two tables have to be compared to find out differerences
between the data. Actually, in SQL, NULL=NULL is neighter true nor
false . Another example: it is not commonly known, but in a unique index,
multiple NULL values are allowed.
- Hard to integrate into a programming language like Java.
- It is case in-sensitive.
- Quoted names that are case sensitive and allow spaces in names.
Other programming languages do not allow spaces, there seems to be no
good reason to support that.
- If there are many columns in a table, 'column counting' is required.
Example: INSERT INTO TEST(many columns) VALUES(many values).
- No syntax for managing databases as a whole.
- No standard UPSERT command (INSERT if the row doesn't exist; UPDATE
if it exists).
- No standard way to detect if a table (index,...) already exists.
- Different products have different namespace mechanisms (schemas,
- Comparing complete rows is not simple, because the complete column
list is required.
- Nobody is trying to clean up the SQL grammar.
What did the ANSI commitee (that defines SQL-92 and SQL-99) wrong?
They didn't do anything wrong. In fact, what they made is absolutely correct.
This commitee consists of the existing database vendors. The standard reflects
as good as possible what these companies have built. The commitee did never
change the behaviour or syntax drastically, because this would break
existing applications, and would mean the existing database vendors would
have to change their existing implementation without a real benefit. Many
database vendors are not interested to standardize everything, because they
could loose existing customers if they did. Many companies live from vendor
lock-in (most applications run only with one, or few, of the existing database
What ANSI did was adding new functionality to the standard. This remindes
a little bit of C++: it is a good language, but very complex, because people
added too much. Java is a new language, and does not have to take all
the old things from the past with it. Java has become very successfull, even
it is only a subset of C++ (well, almost). What is wrong with C++? It is too
complex. What is wrong with SQL? It is too complex, and the products do not
follow the standard. What is wrong with the people that define C++ or SQL?
Are not Object Databases the future?
Object database do not have a big market share at this time. There are several
- There is no standard that is convincing enough (when compared to SQL).
Many relational database system do have now some OODB features, but they
are not widely used.
- The relational databases are more advanced and cheaper when compared
to OODBs (Object Oriented DataBases).
What is the future then?
Hard to say, of course. Maybe OR (Object-Relation) mapping products/standards,
that simplify development. Are Enterprise Java Beans a Object-Relation mapping?
Is JDO (Java Data Objects) the same? But this products are still using an
underlying relational database. Additionally, it looks like the Servlet /
JSP (Java Server Pages) part of J2EE (Java 2 Enterprise Edition) is actually
more successfull than the EJB part. That means developers are using JDBC directly
more than the abstraction of it.
Chances are very good that relational databases will play a very important
role in the software industry in the next years. And even if they do not,
a new data access language will help in any case.
It is time for another data access language.