Re: Do APEX-installed packages include business logic?
From: Yong Huang <yong321_at_yahoo.com>
Date: Mon, 31 Aug 2009 07:32:27 -0700 (PDT)
Message-ID: <705951.55635.qm_at_web80607.mail.mud.yahoo.com>
Thanks again.
Now as I think of it, my concern is more about maintainability than having business logic in the database. Development tools tightly integrated with the database often have two features in this regard: (1) Genarated code is over-engineered; (2) Code is difficult to troubleshoot without the tool. The two features are related. If somebody knows the tool, he doesn't need to dig into the PL/SQL code shown in dba_source, and he won't care and can't tell the code is over-engineered (from the raw PL/SQL perspective). The problem is that these tools, Designer, Forms, etc, and the developers using them, come and go, like clouds in the sky. What stays forever is the RDBMS engine, SQL, and PL/SQL. Our DBA team has three former developers, covering skills in half a dozen languages. But all are proficient in writing code only with Notepad or vi. If either our APEX developers quit or Oracle obsoletes this technology, there'll be some business impact when a user reports a problem. But if the code is completely in the midtier app server, or (slightly less desired) hand-written and stored as PL/SQL, it's easier for anybody to troubleshoot. (The latter case is like my 1997 experience. I was on a team writing thousands of lines of PL/SQL with vi. No extra code is needed. Even the custom-built utility package only needs to provide functions that are needed.)
Date: Mon, 31 Aug 2009 07:32:27 -0700 (PDT)
Message-ID: <705951.55635.qm_at_web80607.mail.mud.yahoo.com>
Thanks again.
Now as I think of it, my concern is more about maintainability than having business logic in the database. Development tools tightly integrated with the database often have two features in this regard: (1) Genarated code is over-engineered; (2) Code is difficult to troubleshoot without the tool. The two features are related. If somebody knows the tool, he doesn't need to dig into the PL/SQL code shown in dba_source, and he won't care and can't tell the code is over-engineered (from the raw PL/SQL perspective). The problem is that these tools, Designer, Forms, etc, and the developers using them, come and go, like clouds in the sky. What stays forever is the RDBMS engine, SQL, and PL/SQL. Our DBA team has three former developers, covering skills in half a dozen languages. But all are proficient in writing code only with Notepad or vi. If either our APEX developers quit or Oracle obsoletes this technology, there'll be some business impact when a user reports a problem. But if the code is completely in the midtier app server, or (slightly less desired) hand-written and stored as PL/SQL, it's easier for anybody to troubleshoot. (The latter case is like my 1997 experience. I was on a team writing thousands of lines of PL/SQL with vi. No extra code is needed. Even the custom-built utility package only needs to provide functions that are needed.)
Yong Huang
- On Sun, 8/30/09, Bill Ferguson <wbfergus_at_gmail.com> wrote:
> From: Bill Ferguson <wbfergus_at_gmail.com>
> Subject: Re: Do APEX-installed packages include business logic?
> To: "chet justice" <chet.justice_at_gmail.com>
> Cc: "Yong Huang" <yong321_at_yahoo.com>, oracle-l_at_freelists.org
> Date: Sunday, August 30, 2009, 12:04 PM
>
> What Chet said.
>
> Apex is great and an easy to create some very sophisticated
> apps, with
> or without the wizards.
>
> Ther is also no way that I know of for a DBA to disable the
> built-in
> PL/SQL routines. Apex itself is built with Apex, so
> disabling the
> PL/SQL routines (two different schemas), would effectively
> disable
> Apex as well.
>
> --
> -- Bill Ferguson
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Aug 31 2009 - 09:32:27 CDT