A while back I spent a couple of days struggling with woefully inadequate documentation trying to get a Progress ESQL program to work. Now, none of this should be rocket science; embedded SQL application programming has been around for ages. Supported languages typically include FORTRAN and COBOL so you know that this is well-established technology! I had spent some time during the weekend reacquainting myself with the requisite skills and had developed a complete application running against DB/2 in about six hours. In fact, I used the DB/2 code as the base for the Progress application. Why the huge difference in effort? The answer lies partially in the state of the RDBMS field in general.

Not so many years ago the RDBMS field was highly competetive. We had companies like Sybase, Ingres, Oracle, Informix, et al, all of them trying to best one another and produce a superior product. Oracle emerged as the unchallenged leader, I believe partially because of their development of add-ons. Oracle Financials, for example, was a precisely targetted solution adopted by a large number of clients. IBM was able to leverage their DB/2 product into second place (largely on the basis of the mainframe and AS/400 markets) while, due to the number of NT servers out there, Microsoft's SQL Server sits in third. Approximate percentages of the RDBMS market ownership are 40%, 20% and 5% respectively.

That leaves only 35% of the market left for the other vendors. With a smaller market share comes smaller net profit, hence smaller R&D budgets. Of course, market share doesn't always indicate the relative merits of the product. Microsoft aggressively markets their SQL Server product as a component of the Back Office suite. Then again, that suite also includes IIS, hardly a stellar example of a web server, not to mention a security nightmare. Microsoft provides an integrated solution which does not require extensive experience in order to install and deploy, however. Some of the other products discussed here require significant knowledge in order to configure and maintain.

While the basic concepts of relational databases are widely known, implementation architectures vary widely. There exist two significantly different approaches to incorporating business logic into the RDBMS model: triggers and stored procedures. Triggers are fired when an attempt is made to insert, modify or delete rows in a table. These triggers can execute a considerable volume of code, performing operations on other tables in order to enforce the business logic. This front-end processing enables simple client applications at the expense of detailed and coherent diagnostic returns.

Stored procedures are quite different from an architectural prespective. Rather than making direct modifications to the tables, a stored procedure encapsulates the business logic in a single method call. It permits complex processing, spanning multiple platforms and distributed databases. Through the use of two-phase commit, the transaction is either successful or completely rolled-out. This is a superior approach to the trigger model in my experience, as trigger programming requires explicit error handling.

My recommendation is to use the most appropriate tool for the job at hand. Unless you're only implementing an intranet solution, the scalability and robustness of SQL Server would be inadequate. Both Oracle and DB/2 are powerful products, although the ease of configuration, installation and maintenance is quite different for each. If you've already invested heavily in Oracle then recommending a migration should be dependant on the size and complexity of the installation. If you're using another RDBMS, your conversion plans should be well underway! In my estimation, DB/2 is the only product I could recommend for a mission-critical back-end.

Recent changes in the licensing structure for Oracle could represent a significant opportunity for IBM. This could be the perfect chance to promote DB/2 as a practical alternative to Oracle 8/9. A cost/benefit analysis could be very educational and many CTOs might be surprised with the results. Given the movement toward Linux server solutions in the face of the proposed Microsoft licensing model, SQL Server could also lose ground to reasonably-priced alternatives. Finally, choose your solution with a jaundiced eye on the longevity of the product and supplier. If you have to migrate, you don't want to do it more than once!

Copyright (c) 2001 by Phil Selby