Re: Business rules in stored procs.
From: Jacco Schalkwijk (NOSPAMjaccos_at_eurostop.co.uk)
Date: 05/07/04
- Next message: DR Tarheel: "Re: Creating a view within a stored procedure"
- Previous message: me_at_privacy.net: "Re: How to do this from DTS?"
- In reply to: David Browne: "Re: Business rules in stored procs."
- Next in thread: anonymous_at_discussions.microsoft.com: "Re: Business rules in stored procs."
- Reply: anonymous_at_discussions.microsoft.com: "Re: Business rules in stored procs."
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 7 May 2004 16:04:10 +0100
The second argument also ties your database design to one specific
application, something relational databases were explicitly invented for to
get rid off.
The last database that I worked on btw that was only accessed by one
application had only 3 tables. Every other database I have ever worked on
was accessed by multiple applications, quite often data imports.OO people
usually don't see imports from other systems as a separate application, but
unless you want to replicate your business rules all over the place or end
up with incorrect data, you better.
The truth as usual lies somewhere in the middle. Keep in mind that as soon
as you even define a datatype in your database (not to mention a foreign key
or a check constraint), you put a business rule in your database, so it's
very hard to avoid having business rules in both your database and your
application.
An interesting counter argument for "you can extrapolated your database from
your application" is made by Dataphor (www.dataphor.com), a framework that
allows you to derive your application from your database design.
-- Jacco Schalkwijk SQL Server MVP "David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in message news:uKoVjEENEHA.2676@TK2MSFTNGP12.phx.gbl... > > "Mark" <anonymous@discussions.microsoft.com> wrote in message > news:9d1401c4343e$2c1273c0$a601280a@phx.gbl... > > I have got into an argument with one of my colleague about > > having business rules in stored procedures. He is saying > > that no business rules should be described by TSQL. The > > rules belong in the middle tier. > > Can someone provide some serious thoughts about the > > subject? > > > Opinion differs on this matter. Also applications differ. Also middle-tier > programming languages differ. > > In fact the one thing that most people agree on is that your application > design should be consolidated in one place, to the extent possible. > > The strongest argument for putting business rules in TSQL is that your > relational design, your constraints and your declarative referential > integrity ARE business rules. Therefore you should consolidate the rest of > the business rules in the same technology and tier. This camp feels that > the distinction between the "data tier" and the "business tier" is a fantasy > made up by people selling middleware technologies and/or O-O snake oil. > > The strongest argument for putting business rules in the middle tier is that > the application processes and procedures, and it's use cases ARE business > rules. Therefore you should consolidate the rest of the business rules in > the same technology and tier. This camp feels that the relational design > can and should be extrapolated (trivially if not automatically) from the > middle tier application design, and that stored procedures just tie your > application to one vendor's RDBMS and add unnecessary complexity to the > application. > > David > >
- Next message: DR Tarheel: "Re: Creating a view within a stored procedure"
- Previous message: me_at_privacy.net: "Re: How to do this from DTS?"
- In reply to: David Browne: "Re: Business rules in stored procs."
- Next in thread: anonymous_at_discussions.microsoft.com: "Re: Business rules in stored procs."
- Reply: anonymous_at_discussions.microsoft.com: "Re: Business rules in stored procs."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
