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

Good points -- I'm about 85% with you.

What I should have made more clear is that I believe a "middle tier" is where the business logic should reside, rather than the database. Perl client A and C++ client B shouldn't be reinventing the same wheel. And you're correct -- middle tier infrastucture (CORBA, Java RMI, DCOM) is still an unproven quantity, at least to our group.

That said, I'd rather have business logic in a small set of well-known Java or C++ class files, rather than in the DB. This is not only for the mechanical and political implementation ease, which may be unique to our organization, but also for my personal perception that stored procedures/ triggers/ PL/SQL are a relatively obscure repository for business logic.

Perhaps it comes down to my belief that I consider a database to be the place where we park the world when we go home at night, rather than where we actually work/compute/do business logic. I might change my mind when Java becomes widely available within Oracle/Sybase/etc.
-- wade

Joe & Anne Buhl wrote:
>
> 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