“SQL was, is, and will stay for the foreseeable future the database language for relational database servers.” That is how we started this book. We know exactly what SQL used to look like and how it looks today. It is beyond doubt that the language will still be the dominant database language for many more years; there is no real competitor yet. But what will SQL look like in the future? We discuss this issue briefly in this chapter.

The integration of SQL and another popular language, Java, has begun and will continue in the coming years. Several SQL products already use Java to specify user-defined data types. A Java class can be used as a new data type in, for example, a CREATE TABLE statement. Another form of integration is that stored procedures will be written in Java; currently, many vendors use their own proprietary language for this. However, other and more powerful forms of integration can easily be invented and will definitely appear on the market.

The most common form of preprogrammed SQL used to be embedded SQL. However, the advent of first client/server technology and later Internet technology decreased the importance of this form. The use of CLIs is increasing. This all started with ODBC, but because of the increasing interest in OLE DB and JDBC, CLIs will eventually become the standard form for programming SQL. Embedded SQL will not disappear but will be pushed to the background.

At the beginning of Chapter 34, “Inheritance, References, and Collections,” we mentioned that object-relational concepts are relatively new at the time of this writing. In fact, the major database vendors began to implement them seriously only in 1997. Many things are still liable to change, and many new object-relational concepts will be added to SQL. Most important is that the merging of OO concepts and SQL has started, and, because of this, the face of SQL will change dramatically over the years.

SQL was born in an era in which databases were mainly used to manage operational data and to create reports. Data warehouses, OLAP, and data mining tools are changing the use of SQL drastically. We have already seen that vendors such as IBM, Microsoft, and Oracle have extended their SQL dialect with facilities that are very useful to OLAP vendors and that increase the speed of SQL. It is to be expected that other vendors will follow their lead and that more concepts, specifically developed for the technologies mentioned, will be added to SQL.

XML has become the language for data exchange. If XML documents are stored in SQL databases, the need arises to manipulate and query those documents. Classic SQL is not suitable for this. XML documents could be regarded as hierarchical objects, and SQL is not capable of handling this kind of objects. That is why vendors have developed extensions to SQL to make it possible to manipulate SQL. An extension called SQL/XML is an example of this. Also, a new database language called XQuery has been developed specifically to store, update, and query XML documents. To what extent XQuery will take the place of SQL, that’s for the future to show.

The performance of SQL products is also improving, and several reasons can be found for this. The products are becoming faster, primarily as the result of the continuous research work done by the vendors. However, development in the field of hardware also leads to faster SQL products. Hard disks and CPUs are becoming faster, and more internal memory is becoming available. All these aspects have a positive impact on the performance of SQL products. And we can say with confidence that those performance improvements will continue for some time. In ten years’ time, we will be laughing at the performance levels that we are very pleased with now.

A less positive expectation is that the portability of SQL will decrease. If we look back at the first edition of this book and compare it with the current version now 20 years later, and look at the number of differences in the SQL dialects of the various products, this number has increased. In the beginning, all products supported almost the same dialect. The differences were minimal, and many differences were dictated by the operating system on which the products ran. Nowadays, the number of differences is much higher and the differences are greater as well. This applies particularly to new areas, such as user-defined data types and object-relational concepts. In short, products are diverging; they are growing apart. It is obvious that the influence of standardization committees such as ISO and ANSI is declining. However, representatives of many of the vendors have representatives on the committees responsible for the SQL standards, which makes the situation very strange.

In spite of these reservations, we expect that SQL will exist for at least another ten years, and its position in the database world is fairly safe. As mentioned in the preface, SQL is intergalactic dataspeak, and there is no competitor on the horizon.