Re: "Business Logic / Rules should never be in the database or stored procedures"

>
> There is an underlying dilemma which I haven't seen any satisfying
> solution to yet: you want enforcement of business rules in the database
> in order to prevent any intentional or unintentional screw up of
> application data. OTOH you want those rules in application code as
> well, because there is where all the business logic resides.
>
> From my experience what often happens is this: some basic business
> constraints are enforced in the database (uniqueness, NOT NULL,
> referential integrity, even some CHECK constraints) while the more
> complex rules live in application code only.
>

>
> Another option would be to place all the business logic in the database
> and treat application logic as glue between UI and database only. With
> Oracle we have a full features programming language that is tightly
> integrated with SQL and would make coding application logic at least
> feasible. This does not seem to be done frequently. Does anybody have
> any experience with that?
>

You all seem to view stored procedures as "part of the database" because they happen to be stored there. If you have a stored procedure that is called from somewhere (as opposed to a trigger), in my view this is just application code like, say, a C program, only it's less integrated in the overall development and tools landscape.

Joachim Received on Sun Dec 13 2009 - 06:41:43 CST