05.11.2015 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS 31<br />

etc.). It covers a SQL MM (multimedia) type, object-relational types, <strong>and</strong> so on. No vendor is<br />

certifying databases to be SQL99 Core or Enhanced “compliant” <strong>and</strong>, in fact, I know of<br />

no vendor who is even claiming that their product is fully compliant with either level of<br />

conformance.<br />

In addition to SQL syntactic differences, implementation differences, <strong>and</strong> differences in<br />

performance of the same query in different databases, there are the issues of concurrency<br />

controls, isolation levels, query consistency, <strong>and</strong> so on. We’ll cover these items in some detail<br />

in Chapter 7 <strong>and</strong> see how their differences may affect you.<br />

SQL92/SQL99 attempts to give a straightforward definition of how a transaction should<br />

work <strong>and</strong> how isolation levels are to be implemented, but in the end, you’ll get different results<br />

from different databases. It is all due to the implementation. In one database, an application<br />

will deadlock <strong>and</strong> block all over the place. In another database, the same exact application will<br />

not do any of these things—it will run smoothly. In one database, the fact that you did block<br />

(physically serialize) was used to your advantage, <strong>and</strong> when you go to deploy on another database,<br />

<strong>and</strong> it does not block, you get the wrong answer. Picking an application up <strong>and</strong> dropping<br />

it on another database takes a lot of hard work <strong>and</strong> effort, even if you followed the st<strong>and</strong>ard<br />

100 percent.<br />

The bottom line is that you should not be afraid to make use of vendor-specific features—<br />

after all, you are paying a lot of money for them. Every database has its own bag of tricks, <strong>and</strong><br />

we can always find a way to perform the operation in each database. Use what is best for your<br />

current database, <strong>and</strong> reimplement components as you go to other databases. Use good programming<br />

techniques to isolate yourself from these changes. I call this defensive programming.<br />

Defensive <strong>Programming</strong><br />

The same defensive programming techniques that I advocate for building truly portable database<br />

applications are, in essence the same as those employed by people writing OS-portable<br />

applications. The goal is to fully utilize the facilities available to you, but ensure you can<br />

change the implementation on a case-by-case basis.<br />

As an analogy, <strong>Oracle</strong> is a portable application. It runs on many operating systems. However,<br />

on Windows it runs in the Windows way: using threads <strong>and</strong> other Windows-specific<br />

facilities. On UNIX, <strong>Oracle</strong> runs as a multiprocess server, using individual processes to do<br />

what threads did on Windows—that is the UNIX way. The “core <strong>Oracle</strong>” functionality is available<br />

on both platforms, but it is implemented in very different ways under the covers. Your<br />

database applications that must function on multiple databases will be the same.<br />

For example, a common function of many database applications is the generation of a<br />

unique key for each row. When you insert the row, the system should automatically generate a<br />

key for you. <strong>Oracle</strong> has implemented the database object called a SEQUENCE for this. Informix<br />

has a SERIAL datatype. Sybase <strong>and</strong> SQL Server have an IDENTITY type. Each database has a way<br />

to do this. However, the methods are different, both in how you do it <strong>and</strong> the possible outcomes.<br />

So, for the knowledgeable developer, there are two paths that can be pursued:<br />

• Develop a totally database-independent method of generating a unique key.<br />

• Accommodate the different implementations <strong>and</strong> use different techniques when<br />

implementing keys in each database.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!