Skip site navigation (1) Skip section navigation (2)

Re: Table Relationships

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Andrew Sullivan <andrew(at)libertyrms(dot)info>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Table Relationships
Date: 2003-05-30 17:20:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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.

In response to


pgsql-performance by date

Next:From: Roman FailDate: 2003-05-30 17:59:51
Subject: Re: Hardware advice
Previous:From: scott.marloweDate: 2003-05-30 17:17:39
Subject: Re: Hardware advice

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group