My wish list as a customer would include
- enable the dba/sysadmin to enable tracing of particular processes. EG I =
want to trace screen 4.=20
Niall Litchfield
Oracle DBA
Audit Commission
+44 117 975 7805 =20
> -----Original Message-----
> From: jaysingh1_at_optonline.net=20
> Sent: 07 February 2004 23:35
> To: jaysingh1_at_optonline.net; oracle-l_at_freelists.org
> Subject: Oracle Development - Best Practice
>=20
>=20
> Dear All,
>=20
> We are starting a new oracle development project and my boss=20
> wants me to
> prepare "Oracle Development- Best practice"=20
> document/presentation kind of
> stuff. Basically this is to avoid common mistakes during the=20
> development
> cycle.
>=20
> I have few points..
>=20
> For example,
>=20
> 1) While writing pl/sql, use the correct datatype so that=20
> implicit conversion
> will be avoided
>=20
> 2) Use bind variable to avoid unnecessary parsing
>=20
> 3) Use BULK COLLECT, % ATTRIBUTES wherever required
>=20
> 4) MODULARITY
> Write the code that fit into your screen size.
> Through successive refinement, you can reduce a complex problem to a
> set of simple problems that have easy-to-implement solutions.
>=20
> 5) EXCEPTION WHEN OTHERS is almost always a BUG unless it is=20
> immediately
> followed by a=20
> RAISE.Use WHEN OTHERS exception as the last resort and handle=20
> exceptions.=20
> For Example,
> EXCEPTION
> WHEN OTHERS THEN
> if (sqlcode=3D-54) then
> .... deal with it.
> else
> RAISE;
> end if;
>=20
>=20
> 6) Tom's Mantra
> =20
> If (possible in SQL)
> do it;
> else if(possible in PL/SQL)
> do it;
> else if(possible in JAVA)
> do it;
> else
> ..
> ..
> end if;
> =20
> 7)% ATTRIBUTES
>=20
> Use %TYPE and %ROWTYPE attributes. No code change is required=20
> when schema
> structure changes.
>=20
> 8) BEFORE VS AFTER TRIGGER
>=20
> NEVER USE BEFORE TRIGGER FOR VALIDATIONS. Use BEFORE triggers ONLY to
> modify :NEW value.
>=20
> AFTER row triggers are slightly more efficient than BEFORE
> row triggers. With BEFORE row triggers, affected data blocks must
> be read (logical read, not physical read) once for the trigger and
> then again for the triggering statement.
> Alternatively, with AFTER row triggers, the data blocks must be
> read only once for both the triggering statement and the trigger.
>=20
> These are only few points w.r.t oracle developers. I like to=20
> get more info
> from you.
>=20
> Your help would be really appreciated.
>=20
> Thanks
> Jay
>=20
> ----------------------------------------------------------------
> 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
> -----------------------------------------------------------------
>=20
>=20
This email contains information intended for
the addressee only. It may be confidential
and may be the subject of legal and/or
professional privilege. Any dissemination,
distribution, copyright or use of this
communication without prior permission of
the sender is strictly prohibited.
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
-----------------------------------------------------------------
Received on Mon Feb 09 2004 - 04:15:32 CST