Database Reference
In-Depth Information
Chapter 1
Developing Successful Oracle
Applications
I spend the bulk of my time working with Oracle database software and, more to the point, with people who
use this software. Over the last 25 years or so, I've worked on many projects—successful ones as well as complete
failures—and if I were to encapsulate my experiences into a few broad statements, here's what they would be:
•
An application built around the database—dependent on the database—will succeed or fail
based on how it uses the database. As a corollary to this, all applications are built around
databases; I can't think of a single useful application that doesn't store data persistently
somewhere.
•
Applications come, applications go. The
data
, however, lives forever. It is not about building
applications; it really is about the data underneath these applications.
•
A development team needs at its heart a core of database-savvy coders who are responsible for
ensuring the database logic is sound and the system is built to perform from day one. Tuning
after the fact—tuning after deployment—means you did not build it that way.
These may seem like surprisingly obvious statements, but in my experience, too many people approach the
database as if it were a black box—something that they don't need to know about. Maybe they have a SQL generator
that will save them from the hardship of having to learn SQL. Maybe they figure they'll just use it like a flat file and do
“keyed reads.” Whatever they assume, I can tell you that thinking along these lines is most certainly misguided; you
simply can't get away with not understanding the database. This chapter will discuss
why
you need to know about the
database, specifically why you need to understand:
•
The database architecture, how it works, and what it looks like.
•
What concurrency controls are, and what they mean to you.
•
How to tune your application from day one.
•
How some things are implemented in the database, which is not necessarily the same as how
you think they should be implemented.
•
What features your database already provides and why it is generally better to use a provided
feature than to build your own.
•
Why you might want more than a cursory knowledge of SQL.
•
That the DBA and developer staff are on the same team, not enemy camps trying to outsmart
each other at every turn.
