Re: Table Relationships

Поиск
Список
Период
Сортировка
Искать
От
scott.marlowe
Тема
Re: Table Relationships
Дата
в 13:37:20
Msg-id
Pine.LNX.4.33.0305301118070.31612-100000@css120.ihs.com
Ответ на
Список
Дерево обсуждения
Re: Select query takes long to execute "Nikolaus Dilger" <nikolaus@dilger.cc>
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 по дате отправления
От: scott.marlowe
Дата:
Сообщение: Re: Hardware advice
От: Roman Fail
Дата:
Сообщение: Re: Hardware advice
FAQ