Re: Generalised approach to storing address details
Date: 15 Dec 2006 01:43:44 -0800
Message-ID: <1166175824.873590.227920_at_16g2000cwy.googlegroups.com>
Sampo Syreeni a écrit :
> On 2006-12-14, Marshall wrote:
>
> > I've never been exactly clear on what the term "network model" means;
> > I've assumed it's quite comparable to an object graph, with which I am
> > quite familiar.
>
> It is.
>
> > Join is not supported. No joins means denormalization is the rule;
> > various offline processes manage the maintenance of the denormalized
> > data. [...] When you ask people why they like it, well, "it's so
> > FAST." (I will admit that it does scale like crazy.)
>
> What you're describing is essentially the OLTP/OLAP tradeoff.
> Denormalized data can be much faster when you're dealing with a
> read-mostly environment with well-understood read patterns, because
> you're basically precomputing, or materializing, all the joins needed by
> your query mixture. This amounts to amortizing the join cost over
> multiple read transactions.
A few points...
--> Individual process response time is one aspect of performance.
Consider conurrency issuesn, cost of ownership, reliability of
information....
--> It is not denormalization that allows to gain speed but the
acceptance of the loss of integrity (with all the known consequences).
Furthermore, to denormalize it would need first to be fully normalized
which is almost never the case...
--> Having data spread out over several tables as opposed to one table
limits the risk of having deadlock appearing. A decent indexing
strategy or view materialization effectively erases the problem of
joins in most cases....
Received on Fri Dec 15 2006 - 10:43:44 CET