Database Reference
In-Depth Information
If you are building a database application,
the most important piece of software is the database.
A successful
development team will appreciate this and will want its people to know about it, to concentrate on it. Many times
I've walked into a project where almost the opposite was true.
A typical scenario would be as follows:
•
The developers were fully trained in the GUI tool or the language they were using to build the
front end (such as Java). In many cases, they had had weeks if not months of training in it.
•
The team had zero hours of Oracle training and zero hours of Oracle experience. Most
had no database experience whatsoever. They would also have a mandate to be “database
independent”—a mandate (edict from management or learned through theoretical academic
instruction) they couldn't hope to follow for many reasons. The most obvious one is they
didn't know enough about what databases are or what they do to even find the lowest
common denominator among them.
•
The developers encountered massive performance problems, data integrity problems,
hanging issues, and the like (but very pretty screens).
As a result of the inevitable performance problems, I now get called in to help solve the difficulties (in the past, as
a learning developer I was sometimes the cause of such issues). On one particular occasion, I couldn't fully remember
the syntax of a new command we needed to use. I asked for the
SQL Reference
manual—and I was handed an Oracle
6.0 document. The development was taking place on version 7.3, five years after the release of version 6.0! It was
all they had to work with, but this did not seem to concern them at all. Never mind the fact that the tool they really
needed to know about for tracing and tuning didn't really exist in version 6. Never mind the fact that features such as
triggers, stored procedures, and many hundreds of others had been added in the five years since that documentation
was written. It was very easy to determine why they needed help—fixing their problems was another issue all together.
■
even today, i often find that the developers of database applications have spent no time reading the
documentation. on my web site, asktom.oracle.com, i frequently get questions along the lines of “what is the syntax
for...” coupled with “we don't have the documentation so please just tell us.” i refuse to directly answer many of those
questions, but rather point them to the online documentation freely available to anyone, anywhere in the world. in the
last 15
years, the excuses like “We don't have documentation,” or “We don't have access to resources,” have virtually
disap
peared. the expansion of the Web and sites like
otn.oracle.com
(the oracle technology network) makes it
inexcusable to not have a full set of documentation at your fingertips! today, everyone has access to all of the
documentation; they just have to read it or—even easier—search it.
Note
The very idea that developers building a
database application
should be shielded from the database is amazing
to me, but that attitude persists. Many people still insist that developers can't take the time to get trained in the
database and, basically, that they shouldn't have to know anything about the database. Why? Well, more than once
I've heard “... but Oracle is the most scalable database in the world, my people don't have to learn about it, it'll just
work.” That's true; Oracle is the most scalable database in the world. However, I can write bad code that does not scale
in Oracle as easily—if not more easily—as I can write good, scalable code in Oracle. You can replace Oracle with any
piece of software and the same is true. This is a fact: it is easier to write applications that perform poorly than it is to
write applications that perform well. It is sometimes too easy to build a single-user system in the world's most scalable
database if you don't know what you are doing. The database is a tool and the improper use of any tool can lead to
disaster. Would you take a nutcracker and smash walnuts with it as if it were a hammer? You could, but it wouldn't be
a proper use of that tool and the result would be a mess (and probably some seriously hurt fingers). Similar effects can
be achieved by remaining ignorant of your database.
