Re: difficult JOIN - Mailing list pgsql-general

From Jim C. Nasby
Subject Re: difficult JOIN
Date
Msg-id 20050127012929.GM67721@decibel.org
Whole thread Raw
In response to Re: difficult JOIN  (Thomas Chille <thomas.chille@gmail.com>)
List pgsql-general
On Wed, Jan 26, 2005 at 11:22:48AM +0100, Thomas Chille wrote:
> In the meanwhile i gave every record an position counter (per tour and
> employee), derrived from begin_time, per trigger, and merged them in
> this way:

How are you generating the position counter? A sequence? If you multiply
by some factor it might eliminate the need to re-number everything.

> SELECT * FROM work LEFT JOIN plan USING(id_tour, id_employee, counter)
> UNION
> SELECT * FROM work RIGHT JOIN plan USING(id_tour, id_employee, counter)
>
> Thats works for me but if the tourleader change one worktime record
> the counters have to be recalculate and the order of the records will
> change.
>
> This is hard to handle and i think i will do all merging
> programmatically in the app or with an ppgsql function.
>
> > BTW, I've never seen the convention id_employee; people generally use
> > employee_id. Is it more important to know that you're talking about an
> > ID or that you're talking about an employee? Just food for thought.
>
> I'm not the father of this strange naming convention :)

I hate getting stuck with other people's stupidity. :)
--
Jim C. Nasby, Database Consultant               decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

pgsql-general by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: self-join on subselect
Next
From: PFC
Date:
Subject: Re: Extended unit