Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS 35
for different vendors method and use stored procedures heavily. This apparently seems to
increase the amount of time it would take to implement on a different database. However, you
will find it is actually easier to implement on multiple databases with this approach. Instead of
having to find the perfect SQL that works on all databases (perhaps better on some than on
others), you implement the SQL that works best on that database. You can do this outside of
the application itself, giving you more flexibility in tuning the application. You can fix a poorly
performing query in the database itself, and deploy that fix immediately, without having to
patch the application. Additionally, you can take advantage of vendor extensions to SQL using
this method freely. For example, Oracle supports hierarchical queries via the CONNECT BY operation
in its SQL. This unique feature is great for resolving recursive queries. In Oracle, you are
free to use this extension to SQL since it is “outside” of the application (i.e., hidden in the database).
In other databases, you would use a temporary table and procedural code in a stored
procedure to achieve the same results, perhaps. You paid for these features, so you might as
well use them.
This technique of developing a specialized layer of code for the database on which you
will deploy is the same as that used by developers who implement multiplatform code. Oracle
Corporation, for example, uses these techniques in the development of its own database.
There is a large amount of code (but a small percentage of the database code overall), called
operating system–dependent (OSD) code, that is implemented specifically for each platform.
Using this layer of abstraction, Oracle is able to make use of many native OS features for performance
and integration, without having to rewrite the large majority of the database itself.
The fact that Oracle can run as a multithreaded application on Windows and a multiprocess
application on UNIX attests to this feature. The mechanisms for interprocess communication
are abstracted to such a level that they can be reimplemented on an OS-by-OS basis, allowing
for radically different implementations that perform as well as an application written directly,
and specifically, for that platform.
Another argument for this approach is that finding a single developer (let alone a team of
developers) who is savvy enough to understand the nuances of the differences between Oracle,
SQL Server, and DB2 (let’s limit the discussion to three databases in this case) is virtually
impossible. I’ve worked mostly with Oracle for the last 11 years (mostly, not exclusively). I
learn something new about Oracle every single day I use it. To suggest that I could be expert in
three databases simultaneously and understand what the differences between all three are
and how those differences will affect the “generic code” layer I would have to build is highly
questionable. I doubt I would be able to do that accurately or efficiently. Also consider the fact
that we are talking about individuals here—how many developers actually fully understand or
use the database they currently have, let alone three of them? Seeking to find the unique individual
who can develop bulletproof, scalable, database-independent routines is a Holy Grail
quest. Building a team of developers that can do this is impossible. Finding an Oracle expert, a
DB2 expert, and a SQL Server expert, and telling them “We need a transaction to do X, Y and
Z”—that’s relatively easy. They are told, “Here are your inputs, these are the outputs we need,
and this is what this business process entails,” and from there it is relatively simple to produce
transactional APIs (stored procedures) that fit the bill. Each will be implemented in the best
manner for that particular database, according to that database’s unique set of capabilities.
These developers are free to use the full power (or lack thereof, as the case may be) of the
underlying database platform.