Fwd: Re: Where can I find real-life-examples about ORACLE

From: Tim Sawmiller <sawmillert_at_state.mi.us>
Date: Mon, 23 Apr 2001 11:32:00 -0700
Message-ID: <F001.002EF732.20010423113041@fatcity.com>

attached mail follows:

I'm an admitted purist...I look at denormalized and unnormalized as being the same. I've been on projects that wanted to introduce denormalization because the developers expected a performance issue. After I look at it and disagree, then the war begins. On the other hand, on my latest project, I agreed with a suggested denormalization after I heard all the facts. I like your point about calling it structured denormalization. Makes sense to me.

As far as people making business decisions, why do they need to know about denormalization? That's an implementation issue. If they hired good IT people, then they're ok. If they didn't, they're screwed. Such is life in the big city. We need to get some successes under our belt so we can preach with confidence and having refenceable clients available.

>>> "Eric D. Pierce" <PierceED_at_csus.edu> 04/23/01 02:06PM >>> And I'd be curious to know why you are curious!

What I have gathered so far from the discussion is that normalization zealotry, probably similar to other purist perspectives in life, doesn't get any particularly huge respect in the "real world".

In other words, people that make business decisions have never heard of any "conventional wisdom" that violating normalized db designs will automatically wreck their organization. Like many other things, their IT infrastructure will inefficiently plod along, and suffer the burden of crappy models (grumbling dbas and all....) in spite of a lack of conformance to theoretical orthodoxy.

I would guess that in some cases, an organization's IT folks might be able to present a coherent business case for zealous normalization, but doing so is probably a rare skill, and perhaps even more rarely appreciated by the organization.

Unfortunately the situation for "structured denormalization" is probably about the same, except that it may not have quite the "political" baggage, and so can just be used as a technical method.

ps, don't forget that the word "structured" needs to be in front of "denormalized". on the other hand, "unnormalized" (non-normal) by definition can't be "structured". "unnormalized" implies a *lack* of methodology, whereas "structured denormalization" implies method/rules/order/metrics/analysis/etc.

pss, do you remember reading the Oracle Magazine article on denormalization by Ulka Rogers back in the Oracle v6 (or maybe early v7) days?

On 23 Apr 2001, at 10:15, Tim Sawmiller wrote:

Date sent:              Mon, 23 Apr 2001 10:15:29 -0800
To:                     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>

ORACLE
> I'd be curious to see your definitions of "un-normalized" and "de-normalized"...
>
>
>
> >>> PierceED_at_csus.edu 04/23/01 01:55PM >>>
>
> On 20 Apr 2001, at 19:15, Jared Still wrote:
>
> Date sent: Fri, 20 Apr 2001 19:15:20 -0800
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>
> > >
> > > Well, why would you *not* want to denormalize during design? It seems
> > > to me that (theoretically) ***if*** you are doing "structured"
> > > denormalization correctly, that is exactly when you would want to do
> > > it, no?
> >
> > Unless you detect a performance problem, why denormalize at all?
> >
> > We always have folks that want to denormalize because they *think*
> > there will be a performance problem. This usually occurs because
> > they think that joining 3 or 4 tables will be too slow.
>
>
> I guess I've been under the impression that a good design
> process would be done with proper methods, including having
> (legitimately tested) performance metrics.
>
> Are you saying that is an overly idealistic approach for most
> "real world" situations? :)
>
> ...
>
> > ... Only one table was highly denormalized, and
> > that was nobody could figure out a reasonable way to normalize it. Not sure
> > if I could yet. :)
>
> Well, as i said before, my understanding is that it was
> "unnormalized", which is different from "denormalized".

...

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tim Sawmiller
  INET: sawmillert_at_state.mi.us

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Received on Mon Apr 23 2001 - 13:32:00 CDT