Re: Impossible Database Design?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 17 May 2006 14:08:20 GMT
Message-ID: <o7Gag.8837$A26.223027_at_ursa-nb00s0.nbnet.nb.ca>
>
> Hmm, so probably then I should go for every event gets stored as a
> single entry in the db...
>
>
>
> I prefer to tell a client though that "something doesn't work because
> computers can't yet handle it" rather than "we have to reprogramm
> because the concept was not proof when developed" (I know that it is
> really irrelevant since my client won't go ask me in 243678 why
> something doesn't work but I am just curious to what the best solution
> is)
Date: Wed, 17 May 2006 14:08:20 GMT
Message-ID: <o7Gag.8837$A26.223027_at_ursa-nb00s0.nbnet.nb.ca>
Nikolai Onken wrote:
>>Not really.
>
> Hmm, so probably then I should go for every event gets stored as a
> single entry in the db...
>
>
>>Because an infinite calendar would require infinite memory to represent >>the largest date.
>
> I prefer to tell a client though that "something doesn't work because
> computers can't yet handle it" rather than "we have to reprogramm
> because the concept was not proof when developed" (I know that it is
> really irrelevant since my client won't go ask me in 243678 why
> something doesn't work but I am just curious to what the best solution
> is)
Since the requirement is a figment of your imagination, you would do better by telling the client: "Yes, I can deliver what you need."
> Would you argue that the calendar example I gave is not a working
> infinite calendar (with some constraints, querying into the future is
> only possible on a defined scale)? It still would work like a charm in
> 2432654376 :)
Apparently, you lack comprehension of the terms 'finite' and 'infinite'. I suggest you ponder the difference between them and re-read what I already posted. Received on Wed May 17 2006 - 16:08:20 CEST