[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: To Normalize or Not to Normalize

• To: 'Michael Kay' <mike@s...>, 'XML Developers List' <xml-dev@l...>
• Subject: RE: To Normalize or Not to Normalize
• From: "Bullard, Claude L (Len)" <len.bullard@i...>
• Date: Wed, 14 Dec 2005 10:29:24 -0600

The best aggregate advice so far is to 

1.  Do the historical homework.

2.  Test for performance.

3.  Redesign for optimal performance and maintenance if possible. 
If not, you can wrapper the system and wait until there is time 
to do so factoring in the costs of conversions.  (This is what I 
think many do.)

4.  Fix the names for reuse.  You may have an OLAP in your future 
and business names set by standards are useful here.  If you can't 
do that, document document document.

If one can't do the above, evaluate the cost/profit and decide if 
the task is strategic.  Make the schema decisions up front because 
once in flight, the further you go, the longer the trip back to 
the airport is.

Thanks folks!  Michael, some replies inline below.

len

From: Michael Kay [mailto:mike@s...]

>> Here's a fun question that pits theory against experience. 

>That's your idea of fun?

Yes.  Education and validation.
 
>> You get a job to create a new generation of an old relational 
>> database system.  Upon reading the as-is schema, you discover 
>> some amount of denormalization and gnomic names.  Do you:

>When a system needs significant enhancement, which seems to be the case
>here, my preferred strategy is always to make the new system(*) look as
much
>as possible like the system that I would design if I were starting from
>scratch.

Mine too but that isn't usually practical for systems where there is a 
signifcant legacy of data and users.  The problem can be that by trying 
to make a working system match my ideal, I can break it and for reasons 
that reveal my lack of knowledge or understanding but definitely lose 
the company money and advantage by crippling the customer.

>>(*)or at any rate, those subsystems that need to be changed

>Sometimes that's not possible, usually because the system is too fragile to
>change or because it's impossible to nail down all its interfaces to other
>systems. That situation is no fun at all: the preferred strategy is to find
>another project...

Cut and run is a strategy.  It can mean a change of employer or loss of a 
customer.  Given a system loosely based on standards or on loose standards 
or specifications, it can mean a whole new business.  The other extreme is 
correct:  don't chase bad money.  I can't count the number of RFPs we  
turned down because the complexity, budget and schedule don't sync up, or 
the times we were compelled to take the work (sales guy wants a commission 
and yells louder; someone lost a golf bet; someone wants to vacation in 
that city, etc,) and took a bath.  The middle ground is development that 
favors (say pays for) a strategic set of features.  Sanity doesn't always
prevail.

The extra dimension of complexity is that there may be a third party such 
as a standards committee specifying yet a third schema which is attractive 
but conflicts with the ambitions of another party to field a system based 
on a different schema.

Then yeah, it's a good idea to walk away.

len

• Prev by Date: Re: Best Practice for URI construction?
• Next by Date: RE: Best Practice for URI construction?
• Previous by thread: Re: To Normalize or Not to Normalize
• Next by thread: RE: To Normalize or Not to Normalize
• Index(es):
  • Date
  • Thread