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: | Pine.LNX.4.33.0305301118070.31612-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Roman Fail | 2003-05-30 17:59:51 | Re: Hardware advice |
Previous Message | scott.marlowe | 2003-05-30 17:17:39 | Re: Hardware advice |