Re: A neutral challenge.
Date: Mon, 30 Jun 2003 12:47:06 -0400
Message-ID: <OI_La.85$br7.11547783_at_mantis.golden.net>
"Isaac Blank" <izblank_at_yahoo.com> wrote in message
news:NIYLa.149$6N1.23088370_at_newssvr21.news.prodigy.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news: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...
>
> > > > > 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.
> > > > >
> > > >
> > > > 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.
>
> For one thing, Peter's reasoning does have its merit - you could
easily
> re-use the same desiign and code for another scheduling application.
Another scheduling application would impose a different domain constraint.
> Also, imposing this limitation would probably make the database design
> and code more complex than it should be.
I disagree. I see no reason to believe it would have any effect on complexity; although, it would certainly have an effect on integrity.
> I can easily come up with a simple
> and fast database design using native SQL types for timestamps, but
> enforcing the granularity by means of appropriate database schema and
> constarints will be a little bit challenging.
I suggest this reveals a flaw (or flaws) in SQL. The schedule granularity is simply a domain constraint. Received on Mon Jun 30 2003 - 18:47:06 CEST