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

Business logic in the database has faster access to the data, so if a lot of data is needed ...

   In the application layer it is closer to the user, so when you want to be user friendly ...

> Only Create, Read, Update, and Delete operations belong in stored procedures.

A number of expressions spring to mind that I'd better not put into writing. These architects will probably have functions to retrieve a column from a record, maybe a function where you provide an id and the name of the column, which will be translated using dynamic sql. I've seen programs where three functions were called to retrieve 3 columns from a record. Underneath the complete record was fetched 3 times.

> Reason being that the database cannot process the business rules efficiently nor can they effectively be managed.

Is that so?

  My contention is that they care coming at it from a typical application perspective, not an ERP perspective.
> I can understand workflow logic being externalized (aka Oracle Workflow), but the restricting stored procedures to CRUD operations
> only... would seem to belittle the power of the Oracle database and what it has to offer.

Since you are using Workslow, I suppose performance is no issue? The Oracle database is an awesome instrument, when looked after properly.

>
> Mind you, these other individuals have primary backgrounds and experience with SQL Server. This may be where some of there
> performance short sightedness may come from, you think ?
>

Never underestimate an opponent, and it would be "their" shortsightedness.

> Anyways, am I off my rocker about sayings its a blend, but that there definitely exist many opportunities for the business logic /
> rules to exist in the database... and should.
> BChase
> bsc7080mqcXX_at_myoracleportal.com
> (remove XX to contact)

Quite right. Not that you are of your rocker, that is. Received on Sun Dec 13 2009 - 07:44:42 CST