Re: Normalisation versus optimisation

"James" <jraustin1_at_hotmail.com> skrev i en meddelelse news:a6e74506.0110251904.3c12c180_at_posting.google.com...
> > Three tables: ProductType, ProductVariant and DespatchNumber.
> > 1:n relationship, left to right e.g.
> >
> > ProductType =
> > ProductTypeID, (PRIMARY KEY)
> > ProductTypeDescription
> >
> > ProductVariant =
> > ProductVariantID, (PRIMARY KEY)
> > ProductVariantDescription,
> > ProductTypeID (FOREIGN KEY on ProductType TABLE)
> >
> > DespatchNumber =
> > DespatchNumberID, (PRIMARY KEY)
> > DespatchNumberDescription
> > ProductVariantID (FOREIGN KEY on ProductVariant TABLE)
> >
> > Should I include the following column in DespatchNumber table:
> > ProductTypeID (FOREIGN KEY on ProductType TABLE)
> > Is there any upside or downside to this? Normalisation versus
optimisation.
>
> If ProductType is included in T_DespatchNumber...
> Adv: Higher performance, can resolve ProductType faster.
> Dis: Lower data integrity. You, not the db engine, are responsible for
> keeping the data synchronized.
>
> In an object-oriented database, it could be modeled as below:
>
> ProdType1
> .Descr
> .Variants
> Var1
> .Descr
> .DespatchNos
> DespatchNo1
> .Descr
> DespatchNo2
> DespatchNoN
> Var2
> VarN
> ProdType2
> ProdTypeN
>
> Because XDb is fast and flexible, denormalization is rarely necessary.
> Download your free copy from http://www.xdb1.com

This seems to me a bit off-topic. A question on normalization/denormalization in relation to a RDBMS was raised, your answer seems to promote a product.
What do you btw mean by "(de)normalization " in an objeckt-oriented database (even if it "is rarely necessary")....

Jan Emil Larsen Received on Tue Dec 04 2001 - 14:45:42 CET