Re: "Business Logic / Rules should never be in the database or stored procedures"
Date: Sun, 13 Dec 2009 09:09:12 -0500
Message-ID: <u1t9i5135jpebnuquo9splm5sdbtb1rher_at_4ax.com>
Really appreciate the feedback on this thread. I think also some of this perspective still stems from the what they typically call an application. I was in a meeting one day and one of my lead architects said something in reference to the HR/Payroll application. Unfortunately there is no such beast at our company. It is in truth a module bolted onto the Oracle Application framework. The module on its own could not survive without the underlying framework ...which interesting enough has provisions for storing business rule logic and data containers for rules, etc. to make it work. iExpense, iProcurement, GL, etc. all bolt-ons leverage the shared resources and logic components in serveral areas.
Most other applications, non-Oracle related, all self-contained applications and not parts of a larger thing.
Anyone agree with my observation ?
On Sat, 12 Dec 2009 04:58:42 -0500, BChase <bsc7080xxmqc_at_myoracleportal.com> wrote:
>
>I have run into a differing of opinions in my shop and wish to hear comments from some of our seasoned individuals here.
>
>I am architect within a fortune 500 company. My primary role has served around the Oracle Applications environment and Oracle
>database. We are currently on 11g and 11.5.10 Application tier. We do have Oracle Workflow, but most of our coding is PLSQL based
>stored procedures. From my understanding, there exist a blend of business logic between the database and the application layer for
>the Oracle Applications framework. I say this because of how Oracle expands the OA environment by adding modules. The rules have to
>go somewhere when so many of the framework pieces appear to be the same.
>
>This all came about when an EA standard was posted about not parsing XML within stored procedures for performance reasons. My
>thought maybe it should have been an opportunity to educate and explain how to mitigate performance issues if one needed to pass XML
>objects to stored procedures and parse the information as opposed to a bold sweeping statement.
>
>What is my problem ? Well assuming I am not misinterpeting things, my Enterprise Architect area and some non-Oracle knowledge
>architects feel that the business logic / rules should only be in the application tier. Only Create, Read, Update, and Delete
>operations belong in stored procedures. Reason being that the database cannot process the business rules efficiently nor can they
>effectively be managed. 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.
>
>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 ?
>
>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)
>
>****************************************************************
>Resource Library is now Online _at_ http://www.MyOraclePortal.com
>****************************************************************
Received on Sun Dec 13 2009 - 08:09:12 CST