[
Lists Home |
Date Index |
Thread Index
]
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@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
