A neutral challenge.

#1

Costins challenge was interesting to me, being unfamiliar with oo-dbms
systems. I was not sure that it was quite fair, however, it being very
much non oo-like.
I grab the opportunity to propose another challenge to a conceptually
very simple problem: scheduling of a meeting.

Consider a group of persons who are to have a meeting. This meeting
has to take place at a time where no other meeting for the people
involved takes place, of course.
Each person has a calender where the available (or if you prefer so,
the unavailable time) for that person is noted. As an example, John
might have this calender:

Mon:
11-16: available
Tuesday:
9-11: available
13-16: available

Andrea might have this calender.

Monday:
9-15: available
Tuesday:
10-12: available
13-16: available

The program should list periods where alle attendees are available.
For John and Andrea, the result would be:

Available:
Monday:
11-15
Tuesday:
10-11
13-16

The user should then be able to pick one of the available time-frames
and let the system schedule the meeting at that frame.

I believe this challenge is interesting for both camps as this is a
realistic problem that often has to be solved in practival life. Also
this gives the oo-oriented camp the possibility to have some slight
form of object-orientation (the intervals) and it is not a problem,
that may be modeled directly via some relational join-operation.
After having solved this problem, it would be interesting to extend
the solution to involve not only persons but also other kind of
resources (e.g. a conference room and a projector). What changes would
you hace to but into the original solution (assuming of course that
this problem had been anticipated berforehand).
I do not propose to solve this problem myself, but it would be
interesting to see if others could sketch a solution using their own
favorite DBMS. Of course, the solution must be sound with regards to
criteria such as time-consumption and safety w.r.t. multiple updates.

Kind regards
Peter

#2

Quote:

create table calender

oops! Change that to --> calendar

#3

"Bob Badour" <bbadour (AT) golden (DOT) net> skrev i en meddelelse
news:PykKa.513$ZO6.69202991 (AT) mantis (DOT) golden.net...

Quote:

"Peter Koch Larsen" <pkl (AT) mailme (DOT) dk> wrote in message
news:61c84197.0306250318.71c26eca (AT) posting (DOT) google.com...
Costins challenge was interesting to me, being unfamiliar with oo-dbms
systems. I was not sure that it was quite fair, however, it being very
much non oo-like.
I grab the opportunity to propose another challenge to a conceptually
very simple problem: scheduling of a meeting.

Consider a group of persons who are to have a meeting. This meeting
has to take place at a time where no other meeting for the people
involved takes place, of course.
Each person has a calender where the available (or if you prefer so,
the unavailable time) for that person is noted. As an example, John
might have this calender:

Mon:
11-16: available
Tuesday:
9-11: available
13-16: available

Andrea might have this calender.

Monday:
9-15: available
Tuesday:
10-12: available
13-16: available

The program should list periods where alle attendees are available.
For John and Andrea, the result would be:

Available:
Monday:
11-15
Tuesday:
10-11
13-16

The user should then be able to pick one of the available time-frames
and let the system schedule the meeting at that frame.

I believe this challenge is interesting for both camps as this is a
realistic problem that often has to be solved in practival life. Also
this gives the oo-oriented camp the possibility to have some slight
form of object-orientation (the intervals) and it is not a problem,
that may be modeled directly via some relational join-operation.
After having solved this problem, it would be interesting to extend
the solution to involve not only persons but also other kind of
resources (e.g. a conference room and a projector). What changes would
you hace to but into the original solution (assuming of course that
this problem had been anticipated berforehand).
I do not propose to solve this problem myself, but it would be
interesting to see if others could sketch a solution using their own
favorite DBMS. Of course, the solution must be sound with regards to
criteria such as time-consumption and safety w.r.t. multiple updates.

Kind regards
Peter

Does 'Monday' represent a specific date or a recurring availability on
every
monday?

My intention was that "Monday" was a specific date. Recurring time-schedules
could be a fringe benefit if implemented. A vague description was
intentional, however (although perhaps not wrt. dates ;-), as the proper
layout of tables and so on could possibly be influenced by the chosen
language.

Kind regards
Peter

#4

"Peter Koch Larsen" <pkl (AT) mailme (DOT) dk> wrote

Quote:

"Bob Badour" <bbadour (AT) golden (DOT) net> skrev i en meddelelse
news:PykKa.513$ZO6.69202991 (AT) mantis (DOT) golden.net...
"Peter Koch Larsen" <pkl (AT) mailme (DOT) dk> wrote in message
news:61c84197.0306250318.71c26eca (AT) posting (DOT) google.com...
Costins challenge was interesting to me, being unfamiliar with oo-dbms
systems. I was not sure that it was quite fair, however, it being very
much non oo-like.
I grab the opportunity to propose another challenge to a conceptually
very simple problem: scheduling of a meeting.

Consider a group of persons who are to have a meeting. This meeting
has to take place at a time where no other meeting for the people
involved takes place, of course.
Each person has a calender where the available (or if you prefer so,
the unavailable time) for that person is noted. As an example, John
might have this calender:

Mon:
11-16: available
Tuesday:
9-11: available
13-16: available

Andrea might have this calender.

Monday:
9-15: available
Tuesday:
10-12: available
13-16: available

The program should list periods where alle attendees are available.
For John and Andrea, the result would be:

Available:
Monday:
11-15
Tuesday:
10-11
13-16

The user should then be able to pick one of the available time-frames
and let the system schedule the meeting at that frame.

I believe this challenge is interesting for both camps as this is a
realistic problem that often has to be solved in practival life. Also
this gives the oo-oriented camp the possibility to have some slight
form of object-orientation (the intervals) and it is not a problem,
that may be modeled directly via some relational join-operation.
After having solved this problem, it would be interesting to extend
the solution to involve not only persons but also other kind of
resources (e.g. a conference room and a projector). What changes would
you hace to but into the original solution (assuming of course that
this problem had been anticipated berforehand).
I do not propose to solve this problem myself, but it would be
interesting to see if others could sketch a solution using their own
favorite DBMS. Of course, the solution must be sound with regards to
criteria such as time-consumption and safety w.r.t. multiple updates.

Kind regards
Peter

Does 'Monday' represent a specific date or a recurring availability on
every
monday?

My intention was that "Monday" was a specific date. Recurring
time-schedules
could be a fringe benefit if implemented. A vague description was
intentional, however (although perhaps not wrt. dates ;-), as the proper
layout of tables and so on could possibly be influenced by the chosen
language.

When I attended Chris Date's UCLA Extensions course last year, it occured to
me that subtypes and type generators go a long way to expressing many
recurring events as intervals. If THIRD_THURSDAY is a subtype of THURSDAY is
a subtype of DAY, one might express an event on the third thursday of every
month using an interval type INTERVAL_THIRD_THURSDAY.

The gaps one must cross are that INTERVAL_THIRD_THURSDAY is neither a
subtype of INTERVAL_THURSDAY nor of INTERVAL_DAY and that the calendar
probably schedules events at a finer granularity than days. One would need a
way of recasting interval types so that the third thursdays in one type of
interval become days in a different type of interval, and then combine those
days with a time of day to construct finer granularity schedules.

Obviously declaring types for THIRD_THURSAY and SECOND_WEDNESDAY etc. would
be tedious, so I think type generators for various date and time
granularities probably make sense too.

Back to the scheduling problem you propose, what granularity of schedule did
you envision? I notice all the times are even hours. Is that just
incidental? Or do you propose a calendar to schedule events on an hourly
basis?

#5

Peter Koch Larsen wrote:

Quote:

In my native language, calendar is spelled "kalender" and I presume
the same is the case for you.

It's 'kalenteri' in Finnish.

Quote:

Your solution shows that somehow intervals of some sort would be nice
to have in a RDBMS.... which I already knew.
One slight surprise is that you did not return a D-language solution
(perhaps Alphora). My uneducated guess would be that they would have
some solution to make the result more generic.

I thought I'll stick to a system that can be easily verified.

Quote:

10 minute intervals
seem sensible when we are talking about people calendArs, but what if
we were to adopt the solution to some similar problem (getting hold of
an assembly line of some kind springs to mind - or the simulation of a
microprocessor where you would need e.g. two ALU's and a locked bus -
10 minute intwervals are certainly inappropriate here).

Yes, this solution would probably not scale to such levels. But if you

have something more spesific
in mind I'll give it a try!

regards,
Lauri

#6

Bob Badour wrote:

Quote:

When I attended Chris Date's UCLA Extensions course last year, it occured to
me that subtypes and type generators go a long way to expressing many
recurring events as intervals. If THIRD_THURSDAY is a subtype of THURSDAY is
a subtype of DAY, one might express an event on the third thursday of every
month using an interval type INTERVAL_THIRD_THURSDAY.

The gaps one must cross are that INTERVAL_THIRD_THURSDAY is neither a
subtype of INTERVAL_THURSDAY nor of INTERVAL_DAY and that the calendar
probably schedules events at a finer granularity than days. One would need a
way of recasting interval types so that the third thursdays in one type of
interval become days in a different type of interval, and then combine those
days with a time of day to construct finer granularity schedules.

Obviously declaring types for THIRD_THURSAY and SECOND_WEDNESDAY etc. would
be tedious, so I think type generators for various date and time
granularities probably make sense too.

I think using types for this purpose is a slight overkill. It would be

easy to add a 'day of week' and
a 'day of week in month' column into materialised calendar and just use
them in selection criterias.

regards,
Lauri

#7

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

[snip]

Quote:

Back to the scheduling problem you propose, what granularity of schedule did
you envision? I notice all the times are even hours. Is that just
incidental? Or do you propose a calendar to schedule events on an hourly
basis?

Ideally, my belief is that the granularity should be arbitrarily small
- this will make the solution applicable for other jinds of schedules
as well. If you do choose a specific interval this should be allowed,
but in that case I would expect some explanation as to why this
specific interval was chosen.

For the rest of your post allow me to return later.

Kind regards
Peter

#8

"Peter Koch Larsen" <pkl (AT) mailme (DOT) dk> wrote

Quote:

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

[snip]

Back to the scheduling problem you propose, what granularity of schedule
did
you envision? I notice all the times are even hours. Is that just
incidental? Or do you propose a calendar to schedule events on an hourly
basis?

Ideally, my belief is that the granularity should be arbitrarily small
- this will make the solution applicable for other jinds of schedules
as well. If you do choose a specific interval this should be allowed,
but in that case I would expect some explanation as to why this
specific interval was chosen.

For the rest of your post allow me to return later.

I don't think it makes sense to schedule rooms to the nanosecond. To the
quarter-hour is probably as great a granularity as anyone would ever really
use in practice and to the minute should provide a safe enough margin of
over engineering.

However, I note that, if one has type generators for time types, the
granularity would certainly be an important parameter. Thus one could adapt
the solution to any granularity, and if the product or language supports
generic programming, one could instantiate a calendar or schedule as a
parameterized solution. I should point out that instantiating a schedule
with nanosecond granularity would probably push physical independence beyond
the limits of any tool.

#9

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Quote:

"Peter Koch Larsen" <pkl (AT) mailme (DOT) dk> wrote in message
news:61c84197.0306261140.6454f73c (AT) posting (DOT) google.com...
"Bob Badour" <bbadour (AT) golden (DOT) net> wrote in message
news:<FPrKa.542$5O7.72062052 (AT) mantis (DOT) golden.net>...
[snip]

Back to the scheduling problem you propose, what granularity of
schedule
did
you envision? I notice all the times are even hours. Is that just
incidental? Or do you propose a calendar to schedule events on an
hourly
basis?

Ideally, my belief is that the granularity should be arbitrarily small
- this will make the solution applicable for other jinds of schedules
as well. If you do choose a specific interval this should be allowed,
but in that case I would expect some explanation as to why this
specific interval was chosen.

For the rest of your post allow me to return later.

I don't think it makes sense to schedule rooms to the nanosecond. To the
quarter-hour is probably as great a granularity as anyone would ever
really
use in practice and to the minute should provide a safe enough margin of
over engineering.

Ideally, the database layer should be able to handle any reasonable

granularity and let the front end restrict it to whatever the policies are.

#10

Bob Badour wrote:

Quote:

I think using types for this purpose is a slight overkill. It would be
easy to add a 'day of week' and
a 'day of week in month' column into materialised calendar and just use
them in selection criterias.

This would complicate queries too much. If one wants to see the events on
thursday, one would have to query three or more columns instead of querying
a single interval column.

OK, maybe I am a bit to used to thinking in SQL. How would your solution
look like, using types?

Lauri