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

Re: Flattening a kind of 'dynamic' table

From: Alexandre Leclerc <alexandre(dot)leclerc(at)gmail(dot)com>
To: Dawid Kuroczko <qnex42(at)gmail(dot)com>
Cc: PERFORM <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Flattening a kind of 'dynamic' table
Date: 2005-01-28 14:25:55
Message-ID: 1dc7f0e305012806254e8540f4@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, 28 Jan 2005 09:07:59 +0100, Dawid Kuroczko <qnex42(at)gmail(dot)com> wrote:
> On Thu, 27 Jan 2005 12:43:56 -0500, Alexandre Leclerc
> <alexandre(dot)leclerc(at)gmail(dot)com> wrote:
> > On Thu, 27 Jan 2005 17:27:40 +0100, Dawid Kuroczko <qnex42(at)gmail(dot)com> wrote:
> > > On Thu, 27 Jan 2005 10:23:34 -0500, Alexandre Leclerc
> > > <alexandre(dot)leclerc(at)gmail(dot)com> wrote:
> > > > Here a normal listing of design.product_department_time:
> > > >  product_id | department_id | req_time
> > > > ------------+---------------+----------
> > > >         906 | A             |     3000
> > > >         906 | C             |     3000
> > > >         906 | D             |     1935
> > > >         907 | A             |     1500
> > > >         907 | C             |     1500
> > > >         907 | D             |     4575
> > > >         924 | A             |     6000
> > > >         924 | C             |     1575
> > >
> > > Well, I did something like this recently; it can be done though
> > > maybe not very efficiently...
> > >
> > > Unfortunately we will need a rowtype with all the departaments:
> > > CREATE DOMAIN departaments AS (a int, b int, c int, d int, ...);
> > Thank you for this help Dawid, I'll have to take some time to look at
> > this suggestion. If I must create a domain with all the departments
> > I'll have a problem because the user is creating and deleting
> > departments as it pleases him.
> >
> > Any counter-ideas?
> 
> I have exactly the same problem with my proposal [1]
> I just wish there would be some "native" rows-to-columns
> aggregate.
> 
> [1]: I was thinking about a trigger on a "departaments" table,
> and then recreating the aggregate and view as needed, but
> it isn't the kind of dynamic I had in mind. ;)

Yep, this is the only thing I also tought: a trigger to add / remove
columns when the user add or remove a department... but this is not
exactly what I wanted (this is not a very nice db design, from my
perspective).

Thank you for you help.

-- 
Alexandre Leclerc

In response to

Responses

pgsql-performance by date

Next:From: Pallav KalvaDate: 2005-01-28 15:15:50
Subject: Poor Performance on Postgres 8.0
Previous:From: Sebastian BöckDate: 2005-01-28 12:30:29
Subject: Re: Optimizing Outer Joins

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