Re: Generalised approach to storing address details

From: Cimode <cimode_at_hotmail.com>
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

Original text of this message