Re: standards

  • From: "Markoen Meijerink" <markoen.meijerink@xxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 5 Aug 2004 08:38:57 +0200

L.S.,

This sounds like the application of the ideas of Karl Popper: It is often
easier for Homo Sapiens to know
and to make a decision based on what you don't want. Karl has written about
more things than the
importance of falsification in science.

But being witty is not the point here:

Whether it is about database and infrastructure-standards (OFA) or about
programming-standards
(e.g. CDM):

a good standard is nothing more than a useless, 'dead' book in the closet if
you do not perform
any active checking. If you do nothing about enforcing the standards, you
can almost save you
the effort.

So if you want your oracle files being placed in
/unn/oradata/bla...bla...something then schedule a check
that checks if it is so.
And if you still want to have all your foreign keys to have an index, then
schedule a check to monitor
whether this is so.
I can give many examples of useful, sanitary checks that you should perform
at the schema, instance or
database level.
And also should keep on doing. Maybe you created the initial 10 users
correctly with the right
settings, but the 11-th user is created with e.g. "that nice feature in the
application to
'create user john identified by john' " at some later time without your
knowledge.
If this user ever gets resource privs you 'll know where the objects will
go.

The work is not the writing of the standard, the work is in the programming
of the active checking!
Find a complete standard combined with a complete tool to implement this
notion (we use one of course).
You will be far better off.

Markoen Meijerink

----- Original Message ----- 
From: "Mogens Nørgaard" <mln@xxxxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Thursday, August 05, 2004 1:51 AM
Subject: Re: standards


> Splendid.
>
> And it brings me back to the very valid point Cary made to me some years
> ago when we were in Honolulu together for the OAUG - remember the one
> where Oracle pulled all financial support two weeks before the start of
> the conference?
>
> That was the beginning of the Mark Jarvis Master Plan (MJMP) to kill off
> user groups and get some real messages out to customers instead :).
>
> Anyway, Cary's point was (I think) to focus on worst practices instead
> of best practices. When you constantly look for best practices you will
> always be falling behind reality, and there will be no impetus for
> moving the bar up. If you look for worst practices (things not to do),
> then you'll learn and grow and become smarter and you can steadily add
> to the list... or just move the bar up, up and away.
>
> Mogens
>
>
>
> david wendelken wrote:
>
> > How about:
> >
> > PL/SQL Programmers who use exception blocks like this will be flogged,
then fired from their job.
> >
> > EXCEPTION
> >   WHEN OTHERS THEN
> >      NULL;
> > END;
> >
> > :)
> >
> > -----Original Message-----
> > From: David <thump@xxxxxxxxxxxxxxxx>
> > Sent: Aug 4, 2004 3:45 PM
> > To: oracle-l@xxxxxxxxxxxxx
> > Subject: standards
> >
> > I ahve been asked to write the standards for the company in terms of
> > Oracle databases.
> > I have never done anythign like that before...
> > Anyone have any pointers or skeletons or examples I could review?
> > Cheers
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx
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
-----------------------------------------------------------------

Other related posts: