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

From: Joe & Anne Buhl <jabuhl_at_worldnet.att.net>
Date: 1998/12/08
Message-ID: <366CB33F.D02AACE1_at_worldnet.att.net>#1/1


Sure it's easy and quick to put the logic in the client. But then try and track it down when there is a problem or it needs modification. There is a benefit to approving the logic at your discussion groups. everyone should be aware of what is taking place and problems can be fleshed out then and their.

If you have developers sprinkling business logic all through the application it can become a nightmare to track down. If your going to put the logic on the client you should still have your approval discussion and have a centralized place for your logic. But that still does not stop it from being code dependent.
Write some business rules in a c application or forms and then you have to repeat the logic if you write something else in Perl. If it's in the database it can be used by more applications. CORBA stuff still seems immature. Bottom line is wherever it ends up it needs strict control and proper management
( your weekly discussion).

joe

Joanna Warrens wrote:

> 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 Tue Dec 08 1998 - 00:00:00 CET

Original text of this message