DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
The dialects of each DML (Data Manipulation Language)-Not only have DBMS developers produced many types of DBMS, they have also produced many flavors of the same original standard DML. Codasyl databases and Relational databases both suffer from this problem. As DBMS developers developed their own implementations, they adapted the standard. Many of the additions were added to provide missing functionality and some were added to provide some form of obviously discriminating feature.
What has resulted, however, is a large collection of both Codasyl and Relational DBMSs that do not adhere to the original single standard. The problem is probably more severe in the Relational DBMS area, simply because this class of DBMS has had longer to evolve and there are more products on the market to exacerbate the problem. In the following paragraphs, some of the differences that can occur between the various versions of SQL are explored in more detail.
It can handle dialects of the DML-In general, the majority of database connectivity middleware smoothes out the differences in the dialects between products of the same type. So, for example, a developer can use one standard version of SQL and the middleware will translate this to the dialect used by Oracle, the dialect used by Sybase, the dialect used by Informix, and so on.
These products can handle the differences in semantics and syntax, can potentially handle the difference in status codes and error messages (though not all translation products do), and can occasionally handle name translation. They have problems with data types. Where a developer wants to access a table or record containing data types that the standard API doesnt recognize as a data type, he or she has to use pass thru, meaning an instruction in the native dialect that is simply passed through to the DBMS.
A small number can handle different DMLs-Only a few specialized products can translate the DML of different DBMS types. So, for example, only a few products can translate from one standard version of SQL to the DML used in IDMS. The translation performed by these products is almost entirely limited to translation of query functions, not update functions. So, products such as EDA/SQL, for example, are able to translate from an SQL dialect to the IDMS dialect, but only if the DML is for a query.
Some of these specialized translation products can also help a little with security privilege translation. As you are probably aware, the database administrator can set privileges and passwords for access to data, and for each DBMS this information has to be repeated. This information is often set up differently with different names and passwords. The translation software keeps its own translation files to show the mapping between all the ids. Some products also automatically synchronize their central security database with those of the DBMSs, meaning that an administrator has even less work to do.
So what doesnt it do?-The one thing database connectivity middleware cannot do is protect the developer from having to know he or she is accessing a certain DBMS or from having to know how that DBMS works. He or she may be able to use a single API, but the developer still has to understand the effect of that API within that DBMShow it affects performance, how it affects the integrity of the data, and so on. Runtime services such as locking, deadlock detection, optimization, and so on all work differently in each DBMS, and all affect the workings of the DBMS differently. You could write a single line of common SQL code for Oracle and the performance could be fine, but in Sybase it could be awful, simply because the locking levels are different.
The developer also has to understand the database design, understand the meaning of the fields, and handle all the problems of data duplication, incompatible formats, incompatible coding systems, and so on. This is really the crux of the problem with database connectivity productsthey dont tackle the main problem. What makes access of all these DBMSs so difficult and time consuming is not the differences in the DML, but the awful designs, the lack of documentation, the duplication, and the misuse of data fields by endusers and programmers alike. The real problem isnt actually solved by database connectivity middleware at all.
So, database connectivity middleware looks like promising stuff on the face of it, but in practice it doesnt bring the total transparency it promises and doesnt deliver the levels of productivity improvement often claimed. Nevertheless, one shouldnt knock it. It simplifies things considerably for low- to medium-volume queries as long as the data is reasonably well documented and does not contain too much duplication and too many incompatibilities. Im not sure I would recommend it for high-volume queries or any form of update.
Why? Well, we have seen that you really need to know what you are doing for an update (locking, commit actions, deadlock detection, etc.), and in this case you might just as well use native DML to ensure you get the right result. Similarly, you also need to know what you are doing with high-volume queries to get the best performance, so again it might be better to use native DML where you understand the effect of the command.
Another reason is simply that translation is performed at runtime, which of itself is bound to slow processing down. In fact, most developers know that updates and high-volume queries are often better compiled (as static SQL, for example) as the compiled code provides better performance.
Previous | Table of Contents | Next |