Re: A neutral challenge.
Date: 28 Jun 2003 10:19:25 -0700
Message-ID: <cd3b3cf.0306280919.7a6ab963_at_posting.google.com>
"Isaac Blank" <izblank_at_yahoo.com> wrote in message news:<HSZKa.761$Ks2.68590664_at_newssvr15.news.prodigy.com>...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:UYLKa.588$Sp2.78550140_at_mantis.golden.net...
> > "Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message
> > news:61c84197.0306261140.6454f73c_at_posting.google.com...
> > > "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:<FPrKa.542$5O7.72062052_at_mantis.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.
I explained above why 1 minute granularity is reasonable for scheduling rooms. Why do you think the dbms should ignore systemic constraints allowing applications to enforce them instead? That seems to contradict almost every principle of good database management. Received on Sat Jun 28 2003 - 19:19:25 CEST
