Re: Database programming standards

I came across a very similar question on usenet and posted the following

<question>
I'm on the periphery of a rather large (to me, at least: $10 mil..) project in  which the tech folks flatly say "NO STORED PROCEDURES: NONE, NOT EVER!".

 There's got to be a reason, but I don't know enough to even guess at it.

 Somebody?
</question>

I'd ask. If the answer is all the logic etc belongs in the application explain that there will be 2 corollaries

1. NO DATA LOADS EVER. Key it through the app ALWAYS. even 10 million rows.
2. NO INTERFACES TO OTHER SYSTEMS, EVER. make other systems talk to the app.

They both follow logically from this 'design' rule.

Unfortunately the programmer types reading this thread considered that my suggestion was sensible and of great technical merit :(

I wish you luck with your 'discussions'.

> I'm on the periphery of a rather large (to me, at least: $10 mil..) project in
> which the tech folks flatly say "NO STORED PROCEDURES: NONE, NOT EVER!".
>
> There's got to be a reason, but I don't know enough to even guess at it.
>
> Somebody?

I'd ask. If the answer is all the logic etc belongs in the application explain that there will be 2 corollaries

1. NO DATA LOADS EVER. Key it through the app ALWAYS. even 10 million rows.
2. NO INTERFACES TO OTHER SYSTEMS, EVER. make other systems talk to the app.

They both follow logically from this 'design' rule.

-- 
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com




On Thu, 3 Jun 2004 09:21:51 -0400, Freeman, Donald
<dofreeman_at_state.pa.us> wrote:


> 

> We are undergoing this battle. The project that I am assigned to hired contractors who brought in pl/sql programmers and put 90% of the logic and business rules in the backend implemented as pl/sql.  Now the project end is in sight and all the full-time staff programmers (hired more recently) are .net programmers who want to rip it all out and put it into the front end. Why?  "Because the job will be much easier long-term after they are gone."<g>

> 

> 

> 

> > One standard that I would insist on is that *all* sql will be

> > written in

> > PL/SQL (stored packages, procedures and functions).  The J2EE

> > classes can

> > simply call these objects to perform the sql operation.  This

> > solves all of

> > the bind variable problems.  Of course, this means that they will need

> > oracle back-end specialists.  But it will make your job much easier

> > long-term after they are gone.

> ----------------------------------------------------------------

> Please see the official ORACLE-L FAQ: http://www.orafaq.com

> ----------------------------------------------------------------

> To unsubscribe send email to:  oracle-l-request_at_freelists.org

> put 'unsubscribe' in the subject line.

> --

> Archives are at http://www.freelists.org/archives/oracle-l/

> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html

> -----------------------------------------------------------------

>

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------