in reply to Interview scheduleing in a database

This isn't really a Perl question, but there's plenty of database people here...

One thought is to use a table like this, where e_id is the employee id, i_id is the interviewee id ( assuming separate tables for employees and interviewees, with a primary key ), and the time period is a reference to a time slice. Let's say further that if an employee is unavailable, you schedule a 'dummy' interview with a special interviewee called 'Unavailable' ( id 0 below ). This lets you avoid having to have entries for every possible time slice. The assumption is that employees are available more often than not - otherwise, change 'Unavailable' to 'Available' and test accordingly.
 
e_id  i_id   time_period
-------------------------
 122  204    4
 104  0      6
 122  114    1
 194  0      2
 194  0      3

[download]
In this example, employee 122 has interviews in time segments 1 and 4 ( perhaps 8:30-9:00 and 10:00 - 10:30 ), and employee 194 is unavailable from 9:00 to 10:00.

Does that help?

Replies are listed 'Best First'.
Re: Re: Interview scheduleing in a database
by hardburn (Abbot) on Nov 12, 2002 at 14:54 UTC

    Hrm, intresting. This certainly helps space efficency, but is probably more difficult to code. *sigh* we just can't win.

    Thanks!

[reply]

      The other awy to do it is to use a combination bitmap/tied hash. This way would have a number of distinct drawbacks, but would save you having to use a database (which, IMO, is the better way).

      You could build a bitmap for each employee/employer, and then AND them together to see what's left -- what's left, of course, are the available times for interviews.

      Then, assuming that you get a match, you could tie() to a hash and create a reference in (for instance) the appropriate employer's timeslot that points to the person being interviewed (or you could just enter their name, but I like the idea of a hashref) and use it to print out reports and so forth.

      Now, suddenly, the database method looks a little bit better, no? ;)

[reply]

In Section Seekers of Perl Wisdom