Re: Impossible Database Design?

Nikolai Onken schrieb:
> Hehe.. thats absolutely true!!
> I probably have not enough experience to really start arguing but I am
> still curious whether there actually is a way to set up a db which
> would
>
> 1. allow infinite events (thats what the client wants or it should at
> least I should make him believe he got it)
Outlook stops at the year 4500.
Most pda calendars somewhere at 2100.

> 2. allow the calculation whether ('infinitly') repeating events overlap
> (Is required because I have to see whether a repeating event conflicts
> with another one when adding)
No idea.

> 3. Not have lots of entries per year (say you have a university with
> 5000 students having 12 lessons 40 weeks a year), and is performant
Databases have no problem at all with such dwarfish amounts of data. How long do you expect your students to stay enrolled?

> 4. (allow exceptions: repeat every monday except monday 15th of May
> 2006)
> Pointing out the limits of the computer definitely moves the whole
> issue into perspective - though the problem remains the same and I am
> still curious as to how a workable solution would look like..
You can, of course, describe an entity of arbitrary complexity. You can leave off the end date, have a list of exceptions and so on and do everything in the client. However, at this point you should ask yourself what the point of a database is.

If I was you I'd first ask the customer how long he expects that application to live. If he's realistic, he'll say something in the range of five to ten years.
Then I would convince him that it's much more important to have a migration path to the next system than to allow some stupid infinities inside.
Which in turn would lead to a design where the appointment is described correctly, infinity and all and individual elements of a series are generated from that description up to 2100 a.d. or so.

Lots of Greetings!
Volker

-- 
For email replies, please substitute the obvious.