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

40
CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS
That’s it—now any user with the ONE_SESSION profile can log on only once. When I bring
up this solution, I can usually hear the smacking of a hand on the forehead followed by the
statement “I never knew it could do that!” Taking the time to familiarize yourself with what the
tools you have to work with are capable of doing can save you lots of time and energy in your
development efforts.
The same “keep it simple” argument applies at the broader architecture level. I urge people
to think carefully before adopting very complex implementations. The more moving parts you
have in your system, the more things you have that can go wrong, and tracking down exactly
where that error is occurring in an overly complex architecture is not easy. It may be really
“cool” to implement umpteen tiers, but it is not the right choice if a simple stored procedure
can do it better, faster, and with fewer resources.
I’ve seen projects where application development has been going on for months, with no
end in sight. The developers are using the latest and greatest technologies and languages, but
still the development is not going very fast. It wasn’t that big of an application—and perhaps
that was the problem. If you are building a doghouse (a small woodworking job), you would
not bring in the heavy machinery. You would use a few small power tools, but you wouldn’t
have use for the big stuff. On the other hand, if you were building an apartment complex, you
would have a cast of hundreds working on the project and you would use the big machines—
you would use totally different tools to approach this problem. The same is true of application
development. There is not a single “perfect architecture.” There is not a single “perfect language.”
There is not a single “perfect approach.”
For example, to build my web site, I used HTML DB. It was a smallish application, and
there was a single developer (or two) working on it. It has maybe 20 screens. Using PL/SQL
and HTML DB was the correct choice for this implementation—it did not need a cast of
dozens, coding in Java, making EJBs, 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, etc.), 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 things 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 for a writer.
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’ll discover