RE: Database programming standards
- From: "Justin Cave" <justin@xxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 3 Jun 2004 14:11:18 -0600
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Deen Dayal
Sent: Thursday, June 03, 2004 12:10 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Database programming standards
>From what I gathered on this thread so far
I want to summarize with following
1) Java code should always use bind variables
2) Any open cursors/connection should be closed/released when the work is
finished and when no longer required
3) Keep the Business logic in the database using stored procs and packs
where ever possible to reduce network traffic and to ensure business rules
are always enforced.
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Daniel Fink
Sent: Friday, 4 June 2004 1:54 AM
To: oracle-l@xxxxxxxxxxxxx
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...
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
