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

Re: To Normalize or Not to Normalize

• To: "Bullard, Claude L (Len)" <len.bullard@i...>
• Subject: Re: To Normalize or Not to Normalize
• From: Rick Marshall <rjm@z...>
• Date: Wed, 14 Dec 2005 09:28:46 +1100
• Cc: "'XML Developers List'" <xml-dev@l...>
• In-reply-to: <15725CF6AFE2F34DB8A5B4770B7334EE0BB1FCC4@h...>
• Organization: Zenucom Pty Ltd
• References: <15725CF6AFE2F34DB8A5B4770B7334EE0BB1FCC4@h...>
• User-agent: Mozilla Thunderbird 1.0.6 (X11/20050716)

i'll bite (yes i'm still lurking)

1. normalisation in my experience is nothing but good. sometimes the 
data storage is an issue, but not, in my opinion, the theory. so at 
every opportunity i normalise, particularly with new projects part of 
whose purpose is to fix or extend old projects.

2. but why? well if you've ever built a staircase (or a house etc) 
you'll understand just how critical it is to get the foundation and 
first step correct. if they're right, the rest happens quickly and like 
magic. if they're wrong, no amount of adjustment higher up will make the 
thing work. normalisation of data structures is to me like the 
foundation of the first step and i won't bother with the software if the 
foundation is no good.

before everyone starts with the efficiency, etc arguments about 
denormalisation let me just say this. after 25 years of building large 
scale applications i often get asked my secret to building them. i reply 
with normalisation. then the inquirer starts pointing out all the 
reasons to denormalise. these days i don't argue i just point out that i 
was asked my secret, i offered it, and if you don't like it that's not 
my problem - you now know my secret.

it's very, very hard to maintain/migrate legacy systems. we have 
applications covering pos, retail management, distribution, and 
manufacturing. when the decision was made to move the whole lot to 
browser technologies and xml where appropriate (and there are many 
places where the xml deployment has been at least as good as i 
anticipated) we also took the opportunity to tidy up the system where 
appropriate.

this meant blanket renaming of attrributes to suit the browsers and xml 
as well as the database. it meant reviewing and improving our ideas on 
candidate, primary, and foreign keys and then again changing the 
structures to suit - no mean feat when half a dozen customers are using 
the same copy of the software and you need to make the changes live! 
(the sites can never actually go down).  it meant deciding on new 
strategies for display and management of data, new strategies to 
commicate between cooperating servers.

could we have done this without everything being normalised - i doubt 
it. we use 5th normal form where possible. it makes the structures 
robust and easy to maintain/extend. we do cheat - there is a semantic 
layer that understands the tables and structures so we don't need to 
embed that in programs - and that may be the secret to using fully 
normalised tables.

could we do this without restructuring the names of things? no. could we 
do it without xml? i doubt it. did it take long? you bet - 2 years and 
counting (with 5 years of practice before that).

sorry for the venting, but i do a lot of this sort of thing and 
denormalised data structures are my great nemesis.

rick

ps you can view some of the work in prgress at http://www.zenucom.com/forum

l o g i n as guest@test
p a s s w o r d guest

it's in xul, so you have to be running firefox

Bullard, Claude L (Len) wrote:

>Here's a fun question that pits theory against experience. 
>
>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:
>
>1.  Normalize the system using this opportunity to clean up 
>the apparent legacy.
>
>2.  Leave the fields as-built including names trusting the 
>original designer to have his or her or their reasons for 
>the denormalized schema and the names as good enough.
>
>3.  Leave the fields as-built but fix all of the names to 
>match the labels on the GUI.
>
>Yes, the existing system is still deployed, still being sold, 
>and still being relied upon for mission critical applications. 
>
>Yes the new system will be using XML more than the comma-delimited 
>exports it relied upon before.
>
>Yes, old customers will be upgraded in some yet as unspecified 
>way when the new system goes online.
>
>What is your best strategy?
>
>len
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>!DSPAM:439f32fb324725315134984!
>
>  
>

begin:vcard
fn:Rick  Marshall
n:Marshall;Rick 
email;internet:rjm@z...
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard

• References:
  • To Normalize or Not to Normalize
    • From: "Bullard, Claude L (Len)" <len.bullard@i...>

• Prev by Date: RE: To Normalize or Not to Normalize
• Next by Date: Re: To Normalize or Not to Normalize
• Previous by thread: Re: To Normalize or Not to Normalize
• Next by thread: RE: To Normalize or Not to Normalize
• Index(es):
  • Date
  • Thread