Database Reference
In-Depth Information
For example, to build my web site I used APEX (Application Express). It's a smallish application, there was a
single developer (or two) working on it. It has maybe 20 screens. PL/SQL and APEX was the correct choice for this
implementation—it did not need a cast of dozens, coding in Java, making EJBs, using Hibernate, and so on. It was a
simple problem, solved simply. There are few complex, large-scale, huge applications (we buy most of those today:
our HR systems, our ERP systems, and so on), but there are thousands of small applications. We need to use the
proper approach and tools for the job.
I will always go with the simplest architecture that solves the problem completely over a complex one any day.
The payback can be enormous. Every technology has its place. Not every problem is a nail, so we can use more than a
hammer in our toolbox.
Openness
I frequently see people doing things the hard way for another reason, and again it relates to the idea that we should
strive for openness and database independence at all costs. The developers wish to avoid using closed, proprietary
database features—even those as simple as stored procedures or sequences—because doing so will lock them into a
database system. Well, let me put forth the idea that the instant you develop a read/write application, you are already
somewhat locked in. You will find subtle (and sometimes not-so-subtle) differences between the databases as soon as
you start running queries and modifications. For example, in one database you might find that your
SELECT COUNT(*)
FROM T
deadlocks with a simple update of two rows. In Oracle, you'll find that the
SELECT COUNT(*)
never blocks on a
writer of the data being counted. You've seen the case where a business rule appears to get enforced on one database,
due to side effects of the database's locking model, and does not get enforced in another database. You'll find that,
given the same exact transaction mix, reports come out with different answers in different databases, all because of
fundamental implementation differences. You will find that it is a very rare application that can simply be picked up
and moved from one database to another. Differences in the way the SQL is interpreted (for instance, the
NULL=NULL
example) and processed will always be there.
On one project, the developers were building a web-based product using Visual Basic, ActiveX Controls, IIS server,
and the Oracle database. I was told that the development folks had expressed concern that since the business logic had
been written in PL/SQL, the product had become database dependent and was asked, “How can we correct this?”
I was a little taken aback by this question. In looking at the list of chosen technologies I could not figure out how
being database dependent was a “bad” thing:
•
The developers had chosen a language that locked them into a single operating system
supplied by a single vendor (they could have opted for Java).
•
They had chosen a component technology that locked them into a single operating system
and vendor (they could have opted for J2EE).
•
They had chosen a web server that locked them into a single vendor and single platform (why
not something more open?).
Every other technology choice they had made locked them into a very specific configuration—in fact, the
only
technology that offered them any choice in terms of operating systems was the database.
Regardless of this (they must have had good reasons to choose the technologies they did) we still have a group of
developers making a conscious decision to not use the functionality of a critical component in their architecture, and
doing so in the name of openness. It is my belief that you pick your technologies carefully and then you exploit them
to the fullest extent possible. You paid a lot for these technologies—isn't it in your best interest to exploit them fully?
I had to assume they were looking forward to using the full potential of the other technologies, so why was the database
an exception? This was an even harder question to answer in light of the fact that it was crucial to their success.
We can put a slightly different spin on this argument if we consider it from the perspective of openness. You put
all of your data into the database. The database is a very open tool. It supports data access via a large variety of open
systems protocols and access mechanisms. Sounds great so far, the most open thing in the world.
