Business logic in DB? (was Re: ref_cursor was (Sybase vs Oracle)?)

From: Joanna Warrens <jwarrens_at_ix.netcom.com>
Date: 1998/12/06
Message-ID: <366B1A5C.E08F00FD_at_ix.netcom.com>#1/1


Adrian Hands wrote:
<snip>
> The benefit's of PL/SQLs tight coupling to the database are very
> valuable indeed.
>
> ...however...
>
> my current feeling is that (with Oracle 7, at least) we'd do better to
> use a little less PL/SQL.
> At least take those procedures that run for more than a few minutes and
> move the outer loop to the client/host language so that the client is
> making shorter duration calls to Oracle. This is because PL/SQL can be
> really difficult to debug.

<snip>

Our company has at least a dozen production Sybase servers, each with it's own replicated warm-standby server. Many applications are beginning to make use of subscription replication to distribute data from one production database to another.

Any new or altered table, trigger, or stored procedure must be formally announced at each Monday's tech meeting, and then must be blessed and installed by our dba group.

However, applications that use the databases (perl, C++, Java, etc) generally do not need to be so blessed.

The net result is that it is difficult to embed procedural logic into the database (via stored procs). However, it is quick and easy to embed such logic in a perl/C++/Java program. Also, it's quick and easy to test such logic against production data.

For this reason, I generally recommend against placing business logic in the database. On the other hand, I do like referential integrity constraints, so I'm trying to have my cake and eat it too, I guess.

How do other folks see this? DBAs? Developers? --wade
ps: xposted to c.d.o due to pl/sql mention. Received on Sun Dec 06 1998 - 00:00:00 CET

Original text of this message