From: ME
To: Editor
I recently heard you speak at the Georgia Oracle User Group
on June 18th in Atlanta, and you also signed my book. Thank you.
I just wanted to let you know how much I enjoyed your talk
and how much I appreciate what you are attempting to do. I have been released
from more than one project for trying to do it right!
Please excuse the fact that I do not have a background in
mathematics or science; in fact, I do not even have a degree. Looking at those
around me who do have "Computer Science" degrees, sometimes I think
the fact that I am self-taught could be an advantage! Most schools,
particularly in the information technology curriculum do not teach
people to think and that is sorely evident.
Long ago I used to teach college grads how to write COBOL
programs. That is to say, I had to teach them how to think logically and define
the problem, and how to define a function, so that complexity of the program
could be simplified, understood and coded correctly. The thing that was amazing
to me is that every on every occasion the biggest hurdle was to get students
out of the mindset that they learned in college -- code and debug, code some
more, debug some more, etc. They had been taught to expect this agonizing
"debugging" period and when I told them on day one that I would teach
them how to write programs that ran correctly the first time and every time,
they didn't believe it was possible. I told them I did this because I don't
like reading core dumps! I taught them how to properly design a program instead
of just keying in code. They began to catch on and once they completed their
first programs that ran correctly the first time, it was like a light came on.
They had new joy in their work and our test and fix time was reduced to
practically nothing, despite every effort by the testers to break the code. I
developed about 5 or 6 "framework" programs within which they could
place specific code, because I found that all the solutions would work within
one of these frameworks. I told my students that if you find you must go
outside of the framework to do what you think you must do, then go back and
look at your defining and designing again, because there is something wrong
with your basic design (namely you made it more complex than was necessary).
I do not want to burden you with all this old COBOL stuff,
but I include it only to illustrate a point. Even though writing COBOL programs
is not like relational theory, the thought processes should be the same--logic.
I have never denormalized a model in physical
implementation (I used to be a data modeler; now I am an Oracle DBA) and I find
that with well-tuned code and a well-tuned database, performance is acceptable;
in some cases, better. The real bonus is the fact that the client can rely on
data integrity, which is an amazing fact to them, since they have never had it
before. Sadly, many do not have it now and don't even realize it!
In regard to this, I do have a question that I would like to
have you respond to. I am against the use of triggers in the database. I feel
they are an attempt to make up for sloppy design. I have designed and brought
to production many databases that are normalized and there is not a trigger to
be found (except for the ones Oracle uses in their software). Also, triggers in
a database are a maintenance nightmare, since you have to think about triggers
firing when you don't want them to. I see that some people use them because
they have denormalized and are trying to keep redundant data in sync. I see
that some people use them to populate summary tables, which I feel is not the
best method. I would like your opinion (with explanation) on the use of
triggers in general and please comment on my opinion, as I have had some
battles over this.
From: Fabian Pascal
To: ME
You are not telling me anything new. However, the problem is
more profound than just the database or even computer fields. This society does
not teach people how to think independently and critically and it's
intentional. It's hard to manipulate, control and exploit people who can think
that way. Conformism and the cookbook approach are much more effective for
that. Check out As
Simple As Possible, But Not Simpler. (And make sure you get the errata for the
book from my web site.)
With regard to triggers, since you know relational, my
general answer should be obvious (I also stated in my book): declarative
integrity is superior to triggered procedures, so in that sense you are correct
to be uncomfortable with them. There are also the problems of trigger
formulation being proprietary rather than standard and the difficulty of the DBMS
to fully optimize procedural constraint checking.
However, because most SQL products provide poor integrity
support, if I were to choose between triggers and application code, I would
have to opt for triggers. For anything other than integrity, I would have to
review it on a case-by-case basis.
If you read my chapter on normalization, you ought to recall
that to control redundancy caused by denormalization, relational knowledge is
required in order to figure out the pertinent constraints, before they are
expressed in the trigger language. And I have yet to encounter one practitioner
who, even if he knew such constraints are necessary, could figure those out.
IOW, chances are that many, if not all, integrity triggers are not correct,
particularly since the trigger language makes their formulation quite complex
Posted
08/11/02
[ABOUT]
[QUOTES]
[LINKS]
