Re: Normalization insanity

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

galenboyerdev_at_hotpop.com
Date: 01/13/05 

Date: 13 Jan 2005 12:25:20 -0500

"John Spiegel" <jspiegel@YETANOTHERSPAMHATERc-comld.com> writes:

> Hi all,
>
> I'm wrestling with a new system design and am looking for opinions on where
> to draw the line with normalizing the database. I'm in early design and
> proof-of concept so have started with a very broken out set of data. I have
> identified a number of cases where a many-to-many situation may exist. But
> the times where there's truly a need will be at best uncommon. For example,
> I've got one possibility where it will take eight joins just to get a set of
> customers, primary contacts and contact information.
>
> My background has been smaller systems in smaller shops where somecan barely
> spell DBA. We're getting more resources and moving over to MSSQL. I guess
> my question is how much further into the complexity is typical? Is it
> fairly common to go to the fairly painful layouts, but write more views to
> mitigate the complexity? Or is there really any rule of thumb beyond how
> much masochism you're feeling?

Either you are "masochistic" with the design or you are "masochistic"
with the code. If you normalize properly, then you will only maintain
your attributes in one spot. If you design denormalized, then your
code will have to maintain attributes in multiple spots. Choose your
poison, but I bet you can guess which one has guarantees of
correctness of the data once the app is deployed. 

-- 
Galen Boyer

Relevant Pages

  • Re: Normalization insanity
    ... >> I'm wrestling with a new system design and am looking for opinions on ... >> my question is how much further into the complexity is typical? ... > code will have to maintain attributes in multiple spots. ...
    (microsoft.public.sqlserver.programming)
  • Re: Questions please
    ... as having a coherent role to play in system design. ... that clearly expresses the nature of actual, key domain and use entities ... are certain the system fulfills all use cases within the specifications ... How well does the high level system design mirror, ...
    (comp.object)
  • Re: Filter Sort Annoyance
    ... I read the info that Van sent about normalizing a database. ... why you lose your filter/sort criteria. ... In a well-normalized data design, ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Nearest Common Ancestor Report (XDb1s $1000 Challenge)
    ... And the aim of normalizing is to remove ... > redundant relationships from the design. ... Therefore, non-normalised data *can* be poor design, but it not ... > Why write a trigger if you can use DRI? ...
    (comp.object)
  • Re: Placing Query By Design Grid On Form
    ... Have you never heard of normalizing and normal form 1? ... If your schema is "dynamically" changing, this is an indication of a pretty ... what you still need is some kind of "Query by Form." ... design of the database first. ...
    (microsoft.public.access.formscoding)