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

34
CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS
This issue is compounded by the fact that our transaction is much larger than just outlined.
The UPDATE and SELECT in the example are only two statements of potentially many
other statements that make up our transaction. We have yet to insert the row into the table
with this key we just generated and do whatever other work it takes to complete this transaction.
This serialization will be a huge limiting factor in scaling. Think of the ramifications if
this technique were used on web sites that process orders, and this was how we generated
order numbers. There would be no multiuser concurrency, so we would be forced to do everything
sequentially.
The correct approach to this problem is to use the best code for each database. In Oracle,
this would be (assuming the table that needs the generated primary key is T) as follows:
create table t ( pk number primary key, ... );
create sequence t_seq;
create trigger t_trigger before insert on t for each row
begin
select t_seq.nextval into :new.pk from dual;
end;
This will have the effect of automatically—and transparently—assigning a unique key to
each row inserted. A more performance driven approach would be simply
Insert into t ( pk, ... ) values ( t_seq.NEXTVAL, ... );
That is, skip the overhead of the trigger altogether (this is my preferred approach).
In the first example, we’ve gone out of our way to use each database’s feature to generate
a non-blocking, highly concurrent unique key, and we’ve introduced no real changes to the
application code—all of the logic is contained in this case in the DDL.
■Tip The same effect can be achieved in the other databases using their built-in features or generating
unique numbers. The CREATE TABLE syntax may be different, but the net results will be the same.
Once you understand that each database will implement features in a different way,
another example of defensive programming to allow for portability is to layer your access to
the database when necessary. For example, say you are programming using JDBC. If all you
use is straight SQL SELECTs, INSERTs, UPDATEs, and DELETEs, you probably do not need a layer of
abstraction. You may very well be able to code the SQL directly in your application, as long as
you limit the constructs you use to those supported by each of the databases you intend to
support—and that you have verified work exactly the same (remember the NULL=NULL discussion!).
Another approach that is both more portable and offers better performance is to use
stored procedures to return resultsets. You will discover that every vendor’s database can
return resultsets from stored procedures, but how they are returned is different. The actual
source code you must write is different for different databases.
Your two choices here are either to not use stored procedures to return resultsets or to
implement different code for different databases. I would definitely follow the different code