| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Database programming standards
Many developers dislike storing business logic in the database for a number
of reasons
- In the original conception of the "three-tiered architecture", the middle
tier application server was designed to hold the business logic. A large
number of developers are tied to this and hesitate to move business logic
from the middle tier to the back end. Of course, what you're really doing
is just changing which physical tier a logical tier is implemented on, but
this can be a hard point to articulate.
- Application servers can be scaled out more easily than can database
servers. Throwing an extra machine or two in the application server cluster
is a relatively simple operation. Throwing an extra machine into a database
server cluster, particularly if you're not using RAC everywhere, is much
more complicated. Realistically, very few applications need this sort of
scale out, but there are a few.
- Developers frequently aren't familiar with SQL, so they find it very
difficult to debug applications that have both a Java component and a PL/SQL
component. You need to have two development environments (unless you use
Jdeveloper) to deal with Java and PL/SQL, you may not be able to use your
favorite debugger to step through all the logic (again, unless you use
Jdeveloper), etc. If all the business logic is in the database, you either
need to have lots of development DBA's in your organization or you need to
ensure that there are at least a couple of developers on the project that
are comfortable in Java and PL/SQL. Given the benefits of the
database-centric development model, this seems like an excellent trade-off
to me, but it does probably mean that you need to have more senior people on
the project than if you hire a bunch of developers that only know Java.
- There is an "impedance mismatch" between Java and PL/SQL. Java thinks in
terms of objects, PL/SQL thinks in terms of tables and relations. This
means that you frequently end up needing an object-relational mapping layer,
which you can either roll yourself or for which you can use a number of
existing layers. Either way, though, you have to learn the mapping layer
API, learn its quirks, etc. If you roll your own, that adds some
development overhead-- if you use an existing layer, you may find that there
are bugs that are painful to isolate and fix because the mapping layer is
trying to be too smart for its own good or the mapping layer is generating
SQL poorly in some situation. Finding a workaround in these cases can be a
pain. Overall, though, it is so much easier for a competent PL/SQL
developer to add the appropriate constraints to a table than for a Java
developer to write and maintain those same constraints in the application,
that most projects will end up being delivered more quickly leveraging the
database, even if you have to deal with this mismatch. Convincing
developers of this, though, can be a challenge, since the mapping layer
tasks are obvious on the schedule and the efficiencies that database-centric
development provides are more amorphous.
Justin Cave
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Deen Dayal
Sent: Thursday, June 03, 2004 12:10 PM
To: oracle-l_at_freelists.org
Subject: RE: Database programming standards
>From what I gathered on this thread so far
I want to summarize with following
I want to know from all of you out there: what are the reasons/arguments developers have against #3
In other words are there any genuine practical reasons except what has been mentioned by Mladen about making the app transparent of the RDBMS (which by the way is a very good point, I will bring it up with my management)
Can any body add anything else to the list above?
The application we are about venture on is going to serve a lot of users, at the peak close to 30K and there are going to be a lot of complex business rules and my guess about the size of the DB should be around 500GB
Thanks to all for your help
Deen
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Daniel Fink
Sent: Friday, 4 June 2004 1:54 AM
To: oracle-l_at_freelists.org
Subject: Re: Database programming standards
Gosh, this sounds like a rather heated discussion I had with an expert in the past. His position was that the database was for storing data...only for storing data. No RI, no check constraints, no stored procs, no triggers. His argument was that anything related to business rules belonged in the application layer.
Other bits stripped...
 |
 |