[Date Prev][Date Next][Thread Prev][Thread Next][Interchange by date
][Interchange by thread
]
[ic] Normalized database for the Foundation demo.
Hi,
>Its my experience that you would not normalise the customer information out
>of an order header anyway. If you were to do this, you would effectively be
>able to rewrite order history - which I would consider undesirable.
It's true that it should not be possible to modify order history.
But is order history the same thing as order lines.
In the example I depicted in my original mail, The shop would have tried to
ship to Belarus instead of Belgium. I was just wondering if normalizing
tables would have prevented this from happening if user data was corrected
after the order was placed.
>Interchange was designed to be largely database independent - able for
>function with RDBMS down to even to flat files. Normalising the the nth
>degree would likely force another level of complexity for many people.
>
You're probably right. You know your user base better than I do.
>Additionally, foundation does not have a particularly complex or bloaty
>data structure.
This might partly due to the fact that it is not normalized, but even
normalizing it would keep it simple. We've all seen more complex data
structure.
>Unless you are talking about tables with hundreds of thousands of
>records, would you see a gain in normalising?
I think, yeah. Even for tables with fewer records. Doesn'it make more sense
to query a view (or joined tables) than to query an non-normalized table.
Modifications to tables are 'naturally' made to views (or joined results). I
think that's why DBMS became RDBMS decades ago. But maybe non-normalized do
offer benefits (other than simplicity), I'm just too used to work with
normalized tables.
Cheers,
Dominique.