Overview

So we see that development of time-varying database applications in SQL is possible, but is devilishly difficult. There are proposals before the SQL3 committee for new language constructs that help immensely. How long will we have to wait until such facilities are widely available?

In the near term, developers of time-oriented applications have three choices. The easiest option is to minimize the use of time in the application, reducing the complexity of the SQL needed, as well as the functionality of the delivered application. The second option is to use the concepts and techniques introduced in this book to develop powerful and correct time-oriented applications. Of course, the SQL code required will often be daunting. The last option is to use third-party software to translate temporal queries (expressed in the SQL/Temporal syntax, or a related syntax) into SQL-92. Such translators are already available commercially, and as the market for such middleware matures, their number and sophistication will grow.

In the longer term, vendors will start integrating temporal support into the DBMS itself. Initially, this will be done by simply imposing a middleware translator between the application and the DBMS. While this is architecturally identical to the third option just described, the perception will be that the DBMS itself has temporal support, an important marketing distinction. The vendor can then gradually move the functionality from the middleware component to the internals of the DBMS, retaining the temporal language but gaining in efficiency, with the timing of this transfer from middleware...