Re: Table Relationships - Mailing list pgsql-performance

From scott.marlowe
Subject Re: Table Relationships
Date
Msg-id Pine.LNX.4.33.0305301118070.31612-100000@css120.ihs.com
Whole thread Raw
In response to Re: Table Relationships  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Table Relationships  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-performance
On Fri, 30 May 2003, Josh Berkus wrote:

> Andrew,
>
> > Are you sure you want to say it that strongly?  After all, if you
> > have a data set which needs always to be returned in the same static
> > format, why not just denormalise it?  It's sure faster that way in
> > every system I've ever encountered.
> >
> > It's only when you actually have relations to cope with that it
> > ceases to be an advantage.  So, as usual, it depends on what you're
> > trying to do.
>
> Yeah, I suppose so ... if all they're doing is reporting on a static set of
> data which is not transactional ... sure.  If it's a disposable,
> limited-time-use application.
>
> However, I have yet to see in my professional experience any application that
> was really this way and stayed this way once it was in use ... relations have
> a way of creeping in, and planning for them is less messy than refactoring.

My philosophy has been you store the data normalized, and denormalize it
for performance down the line.

but denormalizing for storage is usually a bad idea, as it allows your
data to get filled with inconsistencies.

It's funny how people start worrying about performance of flat versus
normalized before really looking at the difference between the two first.
On Postgresql and most other databases, there are far more important
concerns to worry about when it comes to performance than whether or not
you're joining a couple tables.


pgsql-performance by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: Hardware advice
Next
From: "Roman Fail"
Date:
Subject: Re: Hardware advice