Re: Impossible Database Design?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 17 May 2006 07:50:26 GMT
Message-ID: <6BAag.8718$A26.221041_at_ursa-nb00s0.nbnet.nb.ca>
>
> Say you have a university with 10.000 (its a real case) students, each
> having 4 lessons a week 35 weeks a year - 1.400.000 records a year only
> for scheduling and then we also have to add tracking information for
> each lesson... (is that actually a lot?)
>
> Why not?
Date: Wed, 17 May 2006 07:50:26 GMT
Message-ID: <6BAag.8718$A26.221041_at_ursa-nb00s0.nbnet.nb.ca>
Nikolai Onken wrote:
> Thanks for all the replies... Probably I really should read the book
> first :) since my question of how such a DB structure looks like is
> still out there...
>
>>Define 'lots'.
>
> Say you have a university with 10.000 (its a real case) students, each
> having 4 lessons a week 35 weeks a year - 1.400.000 records a year only
> for scheduling and then we also have to add tracking information for
> each lesson... (is that actually a lot?)
Not really.
>>You have not been listening. Unless you have an infinite computer, >>you cannot create an infinite calendar.
>
> Why not?
Because an infinite calendar would require infinite memory to represent the largest date.
Wouldn't it depend on the requirements?
Nope. Not at all. It's inherent in the infinite.
As long as you don't
> need to calculate whether events overlap in the future you could make a
> calendar like
[Finite calendar example snipped] Received on Wed May 17 2006 - 09:50:26 CEST