Search Postgresql Archives

Re: difficult JOIN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jim,

thanks for your answer!

> Hrm. So for a given tour, employee, you want to pair the first record in
> plan with the first record in work, and the second record in plan with
> the second record in work?

Yes you understand me well, thats what i'm trying to achieve.

> Doing that will be pretty tricky. I'm not sure you can even do it in a
> single SELECT.

I'm not sure anymore too.

> More important, does it even make sense? What if an employee ends up not
> working at all for one of his/her planned times? Every record after that
> would be completely skewed. Wouldn't it make much more sense to either
> assign an ID to each record in the plan table, and correlate records in
> the work table using that ID, or correlate based on begin and end time?

This report should not be the final thing. It schould only present the
matched times on an easy way and the tourleader can than edit the
worktimes manually. He have to do this after every tour because the
employees are often not using the timerecording unit correct (i'm
talking about restaurants).

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:

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 :)

Thank you again,
Thomas

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux