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

CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS 47
Summary
In this chapter, we have taken a somewhat anecdotal look at why you need to know the database.
The examples I gave throughout are not isolated—they happen every day, day in and day
out. I observe a continuous cycle of these sorts of issues happening.
Let’s quickly recap the key points. If you are developing with Oracle,
• You need to understand the Oracle architecture. You don’t have to know it so well that
you are able to rewrite the server if you want, but you should know it well enough that
you are aware of the implications of using a particular feature.
• You need to understand the locking and concurrency control features, and that every
database implements them differently. If you don’t, your database will give “wrong”
answers and you will have large contention issues, leading to poor performance.
• Do not treat the database as a black box—that is, something you need not understand.
The database is the most critical piece of most applications. Trying to ignore it would
be fatal.
• Solve problems as simply as possible, using as much of Oracle’s built-in functionality as
possible. You paid a lot for it.
• Software projects come and go, and programming languages and frameworks come
and go. We developers are expected to have systems up and running in weeks, maybe
months, and then move on to the next problem. If you reinvent the wheel, you will
never come close to keeping up with the frantic pace of development. Just as you would
never build your own hash table class in Java—since Java comes with one—you should
use the database functionality you have at your disposal. The first step to being able to
do that, of course, is to understand what it is you have at your disposal. I’ve seen more
than one development team get in trouble, not only technically but also on a personal
level, due to a lack of awareness of what Oracle provides for free.
• And building on that last point—software projects come and go, programming languages
come and go—but the data is here forever. We build applications that use data,
and that data will be used by many applications over time. It is not about the application—it
is about the data. Use techniques and implementations that permit the data to
be used and reused. If you use the database as a bit bucket, making it so that all access
to any data must come through your application, you have missed the point. You cannot
ad hoc query your application. You cannot build a new application on top of your
old application. But if you use the database, you’ll find adding new applications,
reports, or whatever to be much easier over time.
So, with those points in mind, let’s continue.