On Fri, 28 Jan 2005 09:07:59 +0100, Dawid Kuroczko <[EMAIL PROTECTED]> wrote: > On Thu, 27 Jan 2005 12:43:56 -0500, Alexandre Leclerc > <[EMAIL PROTECTED]> wrote: > > On Thu, 27 Jan 2005 17:27:40 +0100, Dawid Kuroczko <[EMAIL PROTECTED]> > > wrote: > > > On Thu, 27 Jan 2005 10:23:34 -0500, Alexandre Leclerc > > > <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
