Database Reference
In-Depth Information
Now this may seem like a long list of things to learn before you start, but consider this analogy for a second: if you
were developing a highly scalable, enterprise application on a brand-new operating system (OS), what is the first thing
you'd do? Hopefully you answered, “Find out how this new OS works, how things will run on it, and so on.” If that
wasn't your answer, you'd most likely fail.
Consider, for example, Windows vs. UNIX/Linux. If you are a long-time Windows programmer and were
asked to develop a new application on the UNIX/Linux platform, you'd have to relearn a couple of things. Memory
management is done differently. Building a server process is considerably different—under Windows, you would
develop a single process, a single executable with many threads. Under UNIX/Linux, you wouldn't develop a single
stand-alone executable; you'd have many processes working together. It is true that both Windows and UNIX/Linux
are operating systems. They both provide many of the same services to developers—file management, memory
management, process management, security, and so on. However, they are very different architecturally—much of
what you learned in the Windows environment won't apply to UNIX/Linux (and vice versa, to be fair). You have to
unlearn to be successful. The same is true of your database environment.
What is true of applications running natively on operating systems is true of applications that will run on a
database: understanding that database is crucial to your success. If you don't understand what your particular
database does or how it does it, your application will fail. If you assume that because your application ran fine on
SQL Server, it will necessarily run fine on Oracle, again your application is likely to fail. And, to be fair, the opposite
is true—a scalable, well-developed Oracle application will not necessarily run on SQL Server without major
architectural changes. Just as Windows and UNIX/Linux are both operating systems but fundamentally different,
Oracle and SQL Server (pretty much any database could be noted here) are both databases but fundamentally
different.
My Approach
Before we begin, I feel it is only fair that you understand my approach to development. I tend to take a database-centric
approach to problems. If I can do it in the database, I will. There are a couple of reasons for this—the first and
foremost being that I know that if I build functionality in the database, I can
deploy
it anywhere. I am not aware of a
popular, commercially viable server operating system on which Oracle is not available—from Windows to dozens of
UNIX/Linux systems—the same exact Oracle software and options are available. I frequently build and test solutions
on my laptop, running Oracle 12
c
, Oracle11
g
, or Oracle10
g
under UNIX/Linux or Windows on a virtual machine.
I can then deploy them on a variety of servers running the same database software but different operating systems.
When I have to implement a feature outside of the database, I find it extremely hard to deploy that feature anywhere
I want. One of the main features that makes the Java language appealing to many people—the fact that their programs
are always compiled in the same virtual environment, the Java Virtual Machine (JVM), and so are highly portable—is
the exact same feature that make the database appealing to me. The database is
my
virtual machine. It is
my
virtual
operating system.
So I try to do everything I can in the database. If my requirements go beyond what the database environment can
offer, I do it in Java outside of the database. In this way, almost every operating system intricacy will be hidden from
me. I still have to understand how
my
“virtual machines” work (Oracle, and occasionally a JVM)—you need to know
the tools you are using—but they, in turn, worry about how best to do things on a given OS for me.
Thus, simply knowing the intricacies of this one “virtual OS” allows you to build applications that will perform
and scale well on many operating systems. I don't mean to imply that you can be totally ignorant of your underlying
OS, just that as a software developer building database applications you can be fairly well insulated from it, and
you will not have to deal with many of its nuances. Your DBA, responsible for running the Oracle software, will be
infinitely more in tune with the OS (if he or she is not, please get a new DBA!). If you develop client-server software
and the bulk of your code is outside of the database and outside of a VM (Java virtual machines being perhaps the
most popular VM), of course you'll have to be concerned about your OS once again.
