Unmögliches Datenbank Design?

Hallo,

ich beschäftige mich immer noch mit Datenbanken und Kalendar
Anwendungen..

Ist es möglich eine Datenbank zu erstellen die:

1 Unendliche Wiederholung von Events unterstützt? (Jährlich, jeden
1 Mittwoch im Monat)
2 Query zur Abfrage von überlappenden Serien (Überschneidet sich
diese Serie mit einer anderen? )

Ich denke nicht das es Möglich ist, da man bei unendlicher Länge nie
einen bestimmten Zeitraum bestimmen kann...
Was wäre die am dichtkommenste Lösung? Muss ich mich dann fundamental
für ein System entscheiden in dem jeder Event ein Eintrag in einer DB
ist, oder in welchem ich überlappende Serien nicht überprüfen kann
aber unendlich wiederholende Events unterstütze?
Das ist doch das selbe wie die Unschärferelation oder?
Viele Grüße,

Nikolai

Re: UnmöglichesDatenbank Design?

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Unmögliches Datenbank Design?

Wenn ich es in einer Cron ähnlichen Struktur abspeichere ist es mir
aber nicht möglich die Schnittpunkte zweier Crons abzufragen oder?

Sagen wir ich habe ein Programm das Stunden einer Universität
speichert.
Die Chance, dass ein Kurs unendlich lange läuft ist natürlich nicht
gegeben aber sagen wir einfach es gibt so einen Kurs (alle 5 Tage, für
immer).
Jetzt möchte ich als Admin einen weiteren Kurs einfügen und eine
Warnung bekommen wenn ein Student bereits eine Stunde hat..

Re: UnmöglichesDatenbank Design?

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Unmögliches Datenbank Design?

Andreas Kretschmer wrote:
> Unwahrscheinlich. Sonnabends/Sonntags sicher schon mal nicht, oder?
> Für welchen Zeitraum? die nächsten 200 Jahre? Werden Deine Studenten =
so alt?

Hehe :) hoffentlich nicht....
Das einzige ist, dass ich wen ich jetzt einen Weg herum finde ich mich
immer Ärgern werde, dass folgende Dinge nicht gleichzeitig von einer
Kalenderanwendung unterstützt werden:

1 'Unendlich wiederholende Events'
2 'Voraussage, wann/ob Events sich schneiden um doppelbuchungen zu
Vermeiden'

Könnte man da nicht eine 'Unschärfeberechnung' machen die sagt, am 23
Feb 3045 hat Paul wahrscheinlich Unterricht?

Re: Unmögliches Datenbank Design?

Nikolai Onken schrieb:
> Andreas Kretschmer wrote:
>=20
>>Unwahrscheinlich. Sonnabends/Sonntags sicher schon mal nicht, oder?
>>Für welchen Zeitraum? die nächsten 200 Jahre? Werden Deine Studente=
n so alt?
>=20
>=20
> Hehe :) hoffentlich nicht....
> Das einzige ist, dass ich wen ich jetzt einen Weg herum finde ich mich
> immer Ärgern werde, dass folgende Dinge nicht gleichzeitig von einer
> Kalenderanwendung unterstützt werden:
>=20
> 1. 'Unendlich wiederholende Events'
> 2. 'Voraussage, wann/ob Events sich schneiden um doppelbuchungen zu
> Vermeiden'
>=20
> Könnte man da nicht eine 'Unschärfeberechnung' machen die sagt, am =
23
> Feb 3045 hat Paul wahrscheinlich Unterricht?
>=20

Bitte überleg dir die Sinnhaftigkeit "unendlicher Wiederholungen". Um e=
s=20
mit Keynes zu sagen: 'In the long run we are all dead.'

--=20
HTH,
Fabian

Re: Unmögliches Datenbank Design?

> Bitte überleg dir die Sinnhaftigkeit "unendlicher Wiederholungen".
> Um es mit Keynes zu sagen: 'In the long run we are all dead.'

das stimmt auf jeden Fall :)
Trotzdem frage ich mich, was die beste Loesung fuer dieses Problem ist.
Einen 'unendlichen Kalender' kann man ja mit so folgender Struktur
einfach bauen:

datetime_start
datetime_end
repeat_pattern
series_id

und folgendem Wert:

2005-06-12 12:00:00
"" (ohne definiertes ende, fuer immer)
"5" (alle 5 Tage)
""

Jetzt muss ich nur noch am entprechenden anzuzeigenden Tag die Anzahl
der Tage zwischen dem Datenbank Eintrag (2005-06-12) und dem
angezeigten Tag (z.B. heute) errechnen und dann anzahl_tage % 5
berechnen. Wenn 0 rauskomt faellt der Tag auf Heute oder halt nicht..
Nur: mit dieser Konstruktion kann ich nicht berrechnen ob sich zwei
Eintraege irgendwann! mal ueberschneiden. Und das ist in manchen
Anwendungen benoetigt..

Soweit ich es mir vorstellen kann ist die einzige Moeglichkeit um zu
sehen, ob sich zwei wiederholende Ereignisse irgendwann mal
ueberschneiden, indem ich jeden Termin als einzelnen Eintrag in die DB
schreibe. Das natuerlich schliesst 'unendliche' Wiederholungen aus..

Gibt es da einen Mittelweg?

Re: Unmögliches Datenbank Design?

tach Nikolai,

Nikolai Onken schrieb:
> Einen 'unendlichen Kalender' kann man ja mit so folgender Struktur
> einfach bauen:
>
> datetime_start
> datetime_end
> repeat_pattern
> series_id
>
> und folgendem Wert:
>
> 2005-06-12 12:00:00
> "" (ohne definiertes ende, fuer immer)
> "5" (alle 5 Tage)
> ""
Diese Werte passen nicht zusammen:
- ein Termin ohne Ende kann nicht wiederholt werden.
- ein Termin ohne Ende erzeugt mit sämtlichen späteren Terminen eine
Kollision.

Sinnvoll wäre einen geplanten Endtermin aufzunehmen (geplante Dauer),
mit diesem kannst du deine normale Berechnung durchführen.

Bei endlosen Terminen muß nach Beendigung das tatsächliche Ende
eingetragen werden.


mfG
--> stefan <--

Re: Unmögliches Datenbank Design?

> ein Termin ohne Ende kann nicht wiederholt werden.

Meinst du einen Termin (Geburtstag) oder eine Terminserie?
Eine Terminserie kann doch immer Wiederholt werden oder nicht?

Re: Re: Unmögliches Datenbank Design?

"Nikolai Onken" wrote:

> Einen 'unendlichen Kalender' kann man ja mit so folgender Struktur
> einfach bauen:
>
> datetime_start
> datetime_end
> repeat_pattern
> series_id
>
> und folgendem Wert:
>
> 2005-06-12 12:00:00
> "" (ohne definiertes ende, fuer immer)
> "5" (alle 5 Tage)
> ""

Dein "repeat_pattern" ist vermutlich noch nicht ausgereift. Mal als
Beispiel, wie der Terminplaner in meinem Palm wiederkehrende Termine
aufnimmt:

1. Es gibt verschiedene Wiederholungsperioden
* täglich
* wöchentlich
* monatlich

2. Bestimmte Perioden haben zusätzliche Eigenschaften. Z.B. kann ein
wöchentlich wiederholtes Ereignis an Wochentage gebunden werden.
Z.B. "Beginnend ab Morgen, 9:00 Uhr, jede Woche Donnerstag+Freitag"

3. Zu jedem Termin gibt es Ausnahmen. Z.B. kann ich den o.g. Termin für
Freitag in 4 Wochen löschen.


Die Frage nach Kollisionen wird wesentlich einfacher beantwortbar, wenn
man davon abgeht *jegliche* Kollision in *beliebig* *ferner* Zukunft
erkennen zu wollen (im Prinzip geht das auch, es läuft auf die Lösung
einer -> linearen diophantischen Gleichung hinaus). In der Praxis dürften
eher folgende Fragestellungen relevant sein:

1. habe ich nächste Woche (nächsten Monat) Terminkollisionen? Meist
will man dann einen Termin verschieben, braucht also lediglich
adäquate Vorlaufzeit. Es ist wenig zielführend, heute schon einen
Termin in 5 Jahren verschieben zu wollen.

2. Ich will einen neuen Termin für den xx.yy.zzzz eintragen, gibt es da
eine Kollision?


XL

Re: Unmögliches Datenbank Design?

tach Nikolai,

Nikolai Onken schrieb:
>> ein Termin ohne Ende kann nicht wiederholt werden.
> Meinst du einen Termin (Geburtstag) oder eine Terminserie?
Ein Geburtstag hat ein Anfang und ein Ende und kann daher wiederholt
werden, jährlich.

> Eine Terminserie kann doch immer Wiederholt werden oder nicht?
Ja, aber eine Terminserie (repeat_pattern) muß aus geschlossenen
Terminen (Anfang und Ende) bestehen, da sie sonst keinen Sinn macht.



mfG
--> stefan <--

Re: Unmögliches Datenbank Design?

> Dein "repeat_pattern" ist vermutlich noch nicht ausgereift.

Das war der einzige Weg den ich mir im Moment vorstellen kann um
einfach zu berechnen, ob ein Event auf einen Bestimmten Tag faellt oder
nicht..
Naturelich suche ich im Endeffekt den Weg der mir erlaubt ein Event zu
erstellen was z.B. jeden 1. Montag + Donnerstag im Monat wiederholt.
Gibt is in SQL moeglichkeiten diese Patterns zu berechnen?

Also

2005-06-12 12:00:00
""
"every 1st monday and thursday every second month"
""

und dann sozusagen:

SELECT * FROM Calenar WHERE (NOW()-date) % 'every 1st monday and
thursday every second month' =3D 0

Oder wie muesste das Pattern aussehen damit SQL es berechnen kann?

> im Prinzip geht das auch, es läuft auf die Lösung
> einer -> linearen diophantischen Gleichung hinaus

Das ist aber in Datenbankberechnungen (MySQL) nicht moeglich oder?

Re: =?iso-8859-1?q?Re:_Unmögliches_Datenbank_Design=3F?

"Nikolai Onken" wrote:

>> Dein "repeat_pattern" ist vermutlich noch nicht ausgereift.

> Naturelich suche ich im Endeffekt den Weg der mir erlaubt ein Event zu
> erstellen was z.B. jeden 1. Montag + Donnerstag im Monat wiederholt.

Eben. Wochentage ergeben sich ja noch hypsch modulo 7. Zumindest so
lange, bis der Kalender das nächste Mal umgestellt wird :-O
Zur Erinnerung: Kalender-Umstellungen gabs schon einige in der
Vergangenheit, auch wenn sich noch keiner so recht getraut hat, an
dem 7-Tage Ding zu drehen. Klar, wenn SIE das so will...

Deutlich unerfreulicher sieht das mit Monatstagen aus. Und womöglich
will man ja irgendwann auch noch "Ostern" und andere, ähnlich
irrational gelegte (IMHO) Termine abbilden können.

> Gibt is in SQL moeglichkeiten diese Patterns zu berechnen?

Wot?

> Oder wie muesste das Pattern aussehen damit SQL es berechnen kann?

Wot?

>> im Prinzip geht das auch, es läuft auf die Lösung
>> einer -> linearen diophantischen Gleichung hinaus
>
> Das ist aber in Datenbankberechnungen (MySQL) nicht moeglich oder?

Die Art deiner Fragestellung läßt *unmißverständlich* erkennen, daß du
entweder nicht willig oder nicht fähig bist, dich mit der Theorie
hinter der Materie auseinanderzusetzen.

Die Entscheidung, ob eine LDG Lösungen hat, erfordert eigentlich nur
elementare Mathematik, kann also ganz gut in eine Stored Procedure
gepackt werden. Allerdings halte ich das nur für begrenzt sinnvoll,
weil es entweder keine oder unendlich viele Lösungen gibt. Die
Prozedure wird also bestenfalls als Prädikat taugen - und dann für die
praktische Verwendung z.B. in einem JOIN zu langsam sein.

Irgendwie habe ich den Eindruck, daß hinter deinen Fragen *keine*
praktische Problemstellung steht. Geh, nerv' jemand anderen.


XL

Re: =?iso-8859-1?q?Re:_Unmögliches_Datenbank_Design=3F?

Oioioi,

warum antwortest du mir ueberhaupt?
Wenn meine Fragen nicht ganz deutlich sind dann entschuldige mich
bitte, da dieses Thema relativ neu ist fuer mich und ich im Internet
bis jetzt nicht so viele Seiten finden konnte die sich mit Datenbanken
und Zeit beschaeftigen...
Ich bin absolut willig und hoffentlich auch faehig mich mit der Materie
auseinanderzusetzen nur habe ich bis jetzt noch kein Loesungsansatz
gesehen (Andreas Kretschmers Antwort war die einzige mit einem
Loesungsansatz via CRON Syntax, mit diesem Ansatz frage ich mich nur
wie ich es nach SQL portiere und wie ich Punkt 3 der Bedingungen
erfuelle - unten)
Wenn dir weiterhin meine Problemstellung nicht deutlich ist und es
nicht deutlich war das meine Frage mit einem Wirklichen Problem
zusammenhaengt hier das Problem:

Ich habe einen Kunden, der eine Kalenderanwendung mit folgenden
features haben moechte:

1 Eintaege die sich nach einem frei definierbarem Pattern wiederholen
2 Moeglichkeit 'unendlich' oft wiederholende Eintraege einzufuegen
(wie auch immer das implementiert wird)
3 Moeglichkeit zu ueberpruefen ob sich x wiederholende Eintraege
ueberschneiden
4 Ausnahmen zu erstellen (jeden Montag aber nicht xxx)

Den Kalender gebrauchen bis zu 10.000 Studenten mit jeweils 10 Stunden
pro Woche a ca. 45 Wochen pro Jahr. Ich suche also nach einer
Performanten Loesung..

> Allerdings halte ich das nur für begrenzt sinnvoll,
> weil es entweder keine oder unendlich viele Lösungen gibt.

Ahhh, gut zu Wissen das du das nicht Sinnvoll haelst.. Was aber ist
Sinnvoll?
Danke aber fuer die Antworten.... Wenn irgendjemand ein Konkretes
Beispiel hat mit Tabellenstruktur und Beispiel-Queries die die oben
genannten Punkte beweisen oder Links zu Seiten die sich mit dem Problem
beschaeftigen waere ich sehr dankbar..
Gruss,

Nikolai

Re: =?iso-8859-1?q?Re:_Unmögliches_Datenbank_Design=3F?

Nikolai Onken schrieb:

>
> Ich habe einen Kunden, der eine Kalenderanwendung mit folgenden
> features haben moechte:
>
> 1. Eintaege die sich nach einem frei definierbarem Pattern wiederholen

Beispielsweise an jedem Mittwoch nach Trinitatis, bei dem die
Quersumme der Differenz in Tagen zum 2.3.1972 nicht durch 7 teilbar ist?

Im Ernst: 'frei definierbar' ist eine Forderung, die kein Mensch
ernstlich stellen kann.

> 2. Moeglichkeit 'unendlich' oft wiederholende Eintraege einzufuegen
> (wie auch immer das implementiert wird)

Ist Dein Auftraggeber eine Kirche, oder warum glaubt der an die
Ewigkeit? Es reicht doch für alle praktischen Erfordernisse, wenn man
die Einträg bis 2100 wiederholen kann. Bis dahin gibt's sowieso andere
Technik, dein Kunde ist tot/pleite/übernommen, und *Du* musst
sicherlich keine Wartung mehr für das Produkt leisten.

> 3. Moeglichkeit zu ueberpruefen ob sich x wiederholende Eintraege
> ueberschneiden
> 4. Ausnahmen zu erstellen (jeden Montag aber nicht xxx)

Warum, wenn die Muster doch schon frei definierbar sind? Mir scheint,
dass 4 nur eine Teilmenge von 1 ist.

>
> Den Kalender gebrauchen bis zu 10.000 Studenten mit jeweils 10 Stunden
> pro Woche a ca. 45 Wochen pro Jahr. Ich suche also nach einer
> Performanten Loesung..

Und diese Studenten haben diese Anforderungen? Das scheint mir wenig
glaubwürdig. Ich jedenfalls bin immer gut mit einem Taschenkalender
hingekommen, und unendlich sich wiederholende Termine hatte ich auch
nicht (dann wäre ich vermutlich nicht fertig geworden mit dem Studium,
sondern vor Langeweile gestorben).


>
>> Allerdings halte ich das nur für begrenzt sinnvoll,
>> weil es entweder keine oder unendlich viele Lösungen gibt.
>
> Ahhh, gut zu Wissen das du das nicht Sinnvoll haelst.. Was aber ist
> Sinnvoll?

Sinnvoll ist hier das, was ein *Problem* löst. Nicht das, worauf sich
ein Auftraggeber einen runterholen kann, weil es angeblich ad
infinitum funktioniert.

Interessant ist doch die Frage, *was* die Studenten da speichern
sollen - ich tippe mal auf Vorlesungstermine, Seminare etc. Deren
Zeiten ändern sich doch aber in jedem Semester (jedenfalls war das
früher so). Schon wäre Dein 'Unendlichoftwiederholen'-Wunsch erledigt
- da reichen vier, fünf Monate. 'Frei definierbare Muster' bräuchte
man auch nicht - es reichen sich Wochentage oder sowas wie "1. Montag
im Monat" oder "jeder 2. Dienstag".

Ob sich Einträge überschneiden, kann doch der geneigte Benutzer (der
ja immerhin Abitur haben sollte) trivialerweise selber feststellen.
Mit "Gehirn 1.0" lässt sich das relativ schnell erledigen. Wer noch
mit "Gehirn 0.99" arbeitet, kann ja ein visuelle Darreicheungsform
einstellen, die dann überlappende Termine auf den ersten Blick
erkennen lässt. Abgesehen davon, dass bei "10 Stunden pro Woche"
angesichts von schlappen 50 Stunden, die in 7 Tagen verplanbar sind
(8-18 Uhr), die Überlappungsgefahr ohnehin relativ gering ist. Dazu
kommen natürlich noch andere Randbedingungen wie "Kein Termin ist
kürzer als 60 Minuten, keiner länger als 120" oder ähnliches.

Natürlich kann man auch erstmal beliebig komplexe Anforderungen
definieren, aus denen dann ein unübersichtliches Datenbankdesign folgt
und natürlich eine mit Features überladene Oberfläche ...
Das liefert zumindest Stoff für viele interessante Gespräche und
garantiert eine nicht überschaubare Implementierungszeit.

Re: =?iso-8859-1?q?Re:_Unmögliches_Datenbank_Design=3F?

> Beispielsweise an jedem Mittwoch nach Trinitatis, bei dem die
> Quersumme der Differenz in Tagen zum 2.3.1972 nicht durch 7 teilbar ist?

Hehe, genau :) Zuminstest die Standard Patterns wie 'jeden 2ten Montag'
etc...

> Sinnvoll ist hier das, was ein *Problem* löst

Ich finde die Problemstellung interessant und einfach den Kalender bis
2099 zu begrenzen finde ich nicht interessant... natuerlich kann das..
Meine Frage ist ja im ersten Post klar zu lesen. Gibt es ein DB Design
was beide Anforderungen erfuellt? Wenn ja was fuer verschiedene
Loesungsmoeglichkeiten gibt es?

> Ob sich Einträge überschneiden, kann doch der geneigte Benutzer (der
> ja immerhin Abitur haben sollte) trivialerweise selber feststellen.

Nur wenn bekannt ist wann ein Event endet. Ich habe DB Designs gesehen
in denen end_date einfach auf NULL gesetzt wird falls die Serie nicht
enden soll...

> Natürlich kann man auch erstmal beliebig komplexe Anforderungen definie=
ren

Die Anforderung ist nicht beliebig komplex sondern beschreibt ein
klares Szenario:

1 Unendliche Wiederholung von Events unterstützt? (Jährlich, jeden
1 Mittwoch im Monat)
2 Query zur Abfrage von überlappenden Serien (Überschneidet sich
diese Serie mit einer anderen? )

Meine Loesungsvorschlaege:

1 Unterstuetzung von 'unendlichen' Wiederholungen mittels NULL in
date_end
(Nachteil: Ueberschneidungen in der Zukunft koennen nicht berechnet
werden)
2 Alle Events werden einzeln gespeichert.
(Unendliche Wiederholungen werden nicht unterstuetzt)
3 Eine Tabelle mit Patterns und eine mit Einzelevents. Die Patterns
unterstuetzen was auch immer und in einem definierten Zeitfenster
werden die Eintraege in die DB geschrieben.
(Nachteil: ich kann nicht vorhersagen, ob eine fuer immer
wiederholende Eventserie sich mit einer anderen jemals schneidet - muss
ich aber nicht, da ich wenigstens in einem Vorgegebenen Zeitfenster
ueberschneidungen ueberpruefen kann..)

Ansonsten kann ich 'Developing Time-Oriented Database Applications in
SQL' (http://www.cs.arizona.edu/~rts/) jedem empfehlen der die selben
Probleme hat.. Ist wahrscheinlich eins der wenigen Buecher mit
konkreten Anwendungsbeispielen zum Thema...
Wie hat zum Beispiel Google Calendar die DB implementiert?
Gruss,

Nikolai

Re: =?iso-8859-1?q?Re:_=?iso-8859-1=3Fq=3FRe: Unmögliches Datenbank Design=3D3F=3F?

"Nikolai Onken" wrote:

> warum antwortest du mir ueberhaupt?

Ich bin ja prinzipiell bereit zu helfen, aber das hat Grenzen.

Wiederholte Fragen nach Lösungen für unsinnige Problemstellungen
sind z.B. jenseits dieser Grenze. Fragen nach Lösungen, die du dann
"verkaufst" dito.

> Ich habe einen Kunden, der eine Kalenderanwendung mit folgenden
> features haben moechte:
>
> 1. Eintaege die sich nach einem frei definierbarem Pattern wiederholen

Nicht eindeutig. Was ist ein "frei definierbares Pattern"? Wenn es um
Studenten und Wochenstunden geht, ist vermutlich eine Wiederholung vom
Typ "wöchentlich" ausreichend.

> 2. Moeglichkeit 'unendlich' oft wiederholende Eintraege einzufuegen

Das ist unsinnig. Im Zusammenhang mit Studenten und Wochenstunden
dürfte ein Planungsinterval von einem Semester angemessen sein.

> 3. Moeglichkeit zu ueberpruefen ob sich x wiederholende Eintraege
> ueberschneiden

Das ist in Verbindung mit 2. unsinnig.

> 4. Ausnahmen zu erstellen (jeden Montag aber nicht xxx)

Wenn ich das mit deinen bisherigen Angaben vergleiche, scheint mir auch
daß deine Termin-Slots keine ganzen Tage, sondern eher Stunden (oder
Vorlesungseinheiten?) sind. Vermutlich hat eine Lösung eher wenig mit
den gebräuchlichen Datums- und Zeit-Typen in SQL zu tun.


> Den Kalender gebrauchen bis zu 10.000 Studenten mit jeweils 10 Stunden
> pro Woche a ca. 45 Wochen pro Jahr. Ich suche also nach einer
> Performanten Loesung..

Laß mich raten: das ist dein erstes Projekt? Die Frage nach der
Performanz einer Lösung stellt sich erst ziemlich spät. Du hast ja
noch nicht mal ein klares(!) Pflichtenheft.

>> Allerdings halte ich das nur für begrenzt sinnvoll,
>> weil es entweder keine oder unendlich viele Lösungen gibt.
>
> Ahhh, gut zu Wissen das du das nicht Sinnvoll haelst.. Was aber ist
> Sinnvoll?

Ich halte es im gegeben Kontext z.B. nicht für sinnvoll, die
Kollisionserkennung für Termine innerhalb der Datenbank zu machen.
Insbesondere ist es sinnlos, eine SP schreiben zu wollen, die *alle*
zukünftigen Kollisionen von Terminen ausspuckt, weil die entweder
die leere Menge oder unendlich viele Zeilen zurückliefert.

Aber so lange es keine exakten Anforderungen an Terminslots und
Wiederholungsfunktionen gibt, kann man noch nicht mal sagen, wie
man diese Informationen überhaupt abspeichern will. Geschweige denn,
was das für Auswirkungen auf die Effizienz bestimmter Operationen
auf diesen Daten bedeutet.

Unter bestimmten Randbedingungen könnte es durchaus sinnvoll sein,
einer Tabelle einen INSERT/UPDATE Trigger zu verpassen, der neue
(bzw. geänderte) Termine auf Verträglichkeit prüft. Womöglich
skaliert das für 10.000 Nutzer aber besser wenn man das in der
Applikation (Webserver?) macht.


> Wenn irgendjemand ein Konkretes
> Beispiel hat mit Tabellenstruktur und Beispiel-Queries die die oben
> genannten Punkte beweisen oder Links zu Seiten die sich mit dem Problem
> beschaeftigen waere ich sehr dankbar..

Es existieren mehr als nur eine handvoll Kalender-Applikationen
im Web, etliche sind sicher Open Source. Eine naheliegende Idee wäre
also, Sourceforge, Freshmeat und Google nach frei verfügbaren, daten-
bankgestützen Kalenderapplikation abzuklappern.


PS: ganz nebenbei ist diese Diskussion hier deutlich OffTopic. Es gibt
keinen Bezug zu Datenbanken und schon gar nicht zu MySQL.


XL

Re: =?iso-8859-1?q?Re:_Unmögliches_Datenbank_Design=3F?

Nikolai Onken schrieb:
>> Beispielsweise an jedem Mittwoch nach Trinitatis, bei dem die
>> Quersumme der Differenz in Tagen zum 2.3.1972 nicht durch 7 teilbar ist?
>
> Hehe, genau :) Zuminstest die Standard Patterns wie 'jeden 2ten Montag'
> etc...
>

Ich kann Deiner Fragestellung nicht so ganz folgen: Erst soll es "frei
definierbar" sein, und dann hättest Du es gerne "Standard".

>> Sinnvoll ist hier das, was ein *Problem* löst
>
> Ich finde die Problemstellung interessant und einfach den Kalender bis
> 2099 zu begrenzen finde ich nicht interessant... natuerlich kann das..

'interessant' im Sinne von 'ich habe gerade nichts anderes zu tun als
über etwas nachzudenken, was keinerlei praktische Bedeutung hat'?
Andererseits frage ich mich, warum Du dann den erwähnten Mittwoch nach
Trinitatis mit den paar trivialen Randbedingungen nicht "interessant"
findest. Weshalb diese plötzliche Beschränkung auf praktisch Relevantes?

> Meine Frage ist ja im ersten Post klar zu lesen. Gibt es ein DB Design
> was beide Anforderungen erfuellt? Wenn ja was fuer verschiedene
> Loesungsmoeglichkeiten gibt es?
>
>> Ob sich Einträge überschneiden, kann doch der geneigte Benutzer (der
>> ja immerhin Abitur haben sollte) trivialerweise selber feststellen.
>
> Nur wenn bekannt ist wann ein Event endet.

Trivialerweise enden für mich alle Events mit meinem Lebensende. Nimm
mein Alter + die statistische Lebenserwartung + 50 Jahre
Sicherheitsabstand, schon weißt Du, wann der Event endet (und ich
auch). In der Praxis allerdings enden Events für Studenten (um die
ging es doch, oder?) spätestens mit der Exmatrikulation, vermutlich
aber schon mit dem Semesterende.

> Ich habe DB Designs gesehen
> in denen end_date einfach auf NULL gesetzt wird falls die Serie nicht
> enden soll...
>

Lustigerweise gehst Du gar nicht darauf ein, was die *Kunden* wirklich
brauchen könnten. Ich vermute mal: Die wollen in *endlicher* Zeit eine
brauchbare Anwendung. Und das könnte man dadurch erreichen, dass man
eine sinnvolle Teilmenge der abstrakten unendlichen Anforderungen
implementiert.


>> Natürlich kann man auch erstmal beliebig komplexe Anforderungen definieren
>
> Die Anforderung ist nicht beliebig komplex sondern beschreibt ein
> klares Szenario:
>
> 1. Unendliche Wiederholung von Events unterstützt? (Jährlich, jeden
> 1. Mittwoch im Monat)

Vorher waren es noch 'frei definierbare Muster'.

> 2. Query zur Abfrage von überlappenden Serien (Überschneidet sich
> diese Serie mit einer anderen? )
>

Erklär' doch mal, wo da der Anwendungsfall liegt: Warum muss ich jetzt
wissen, was sich in zwei Jahren (oder gar in 50) überlappt?

> Meine Loesungsvorschlaege:
>
> 1. Unterstuetzung von 'unendlichen' Wiederholungen mittels NULL in
> date_end
> (Nachteil: Ueberschneidungen in der Zukunft koennen nicht berechnet
> werden)

Da man mit 'Unendlich' ohnehin schlecht rechnen kann, ist das kein
Beinbruch. Überschneidungen in der Vergangenheit interessieren
vermutlich keinen. Also meinst Du: Du kannst damit gar keine
Überschneidungen berechnen. Was die Nützlichkeit etwas fragwürdig
erscheinen lässt.

> 2. Alle Events werden einzeln gespeichert.
> (Unendliche Wiederholungen werden nicht unterstuetzt)

Alles eine Frage der Zeit und des Plattenplatzes.

Du könntest ja Unendlichkeit durch eine zyklische Liste simulieren:
Erstmal alles bis 2099 eintragen. Und dann am Ende jedes Tages (MySQL
5.1 kann Events) dessen Daten löschen und die sich wiederholenden
Einträge im Jahr 2100 einfügen ... Wahlweise partitionieren (kann
MySQL auch) und immer neue Platten anhängen ...

> 3. Eine Tabelle mit Patterns und eine mit Einzelevents. Die Patterns
> unterstuetzen was auch immer und in einem definierten Zeitfenster
> werden die Eintraege in die DB geschrieben.

So richtig unendlich finde ich das nicht.

> (Nachteil: ich kann nicht vorhersagen, ob eine fuer immer
> wiederholende Eventserie sich mit einer anderen jemals schneidet - muss
> ich aber nicht, da ich wenigstens in einem Vorgegebenen Zeitfenster
> ueberschneidungen ueberpruefen kann..)
>

Man könnte auch einen unendlich langen Zettel nehmen (Turingmaschine!)
und einfach alle Termine auf dem eintragen. Wenn an einer Stelle schon
was steht, ist da eine Überlappung.

Re: =?iso-8859-1?q?Re:_=?iso-8859-1=3Fq=3FRe: Unmögliches Datenbank Design=3D3F=3F?

Hey Axel,

danke fuer deine ausfuerliche Antwort!!

> Wiederholte Fragen nach Lösungen für unsinnige Problemstellungen
> sind z.B. jenseits dieser Grenze.

Ich finde diese Problemstellung absolut nicht unsinnig - vielleicht
nicht richtig in diesem Forum, aber nach einer Loesung zu suchen die
Ueberschneidungen in der Zukunft finden kann und gleichzeitig
'unendliche' Wiederholung unterstuetzt finde ich viel interessanter als
'Wo speichere ich am besten Inventarobjekte ab die nicht mehr im
Inventar existieren' oder wie finde ich den Maximalwert einer Spalte :)

> Fragen nach Lösungen, die du dann "verkaufst" dito.

Die Loesung ist fuer jeden der moechte in dieser Newsgroup einsichtig.
Ich denke nicht, dass meine Frage nur interessant fuer mich ist.
Trotzdem bin ich fuer jede Hilfe dankbar und ich gebe sicher meinen
Beitrag in anderen Foren zu anderen Themen..

> Aber so lange es keine exakten Anforderungen an Terminslots und
> Wiederholungsfunktionen gibt,

Wiederholungsfunktionen sind die folgende: jeden Montag, alle 3 Tage,
jeden 2, 5ten Tag im Monat.
In meinem Fall gibt es in der Anwendung Stunden (z.B. 60 Minuten),
Ferien, Projektwochen, Semester, Events (Abschlussfeier, etc.)
Ist es da nicht besser so allgemein wie moeglich zu modellieren? Was
wenn der Kunde kommt und sagt 'xxx' und das ist nicht implementiert und
erfordert tiefgreifende Aenderungen. Das moechte ich vermeiden..

> Ich halte es im gegeben Kontext z.B. nicht für sinnvoll, die
> Kollisionserkennung für Termine innerhalb der Datenbank zu machen.

Ich habe wahrscheinlich nicht genug Erfahrung aber ich denke mir das
Kollisionserkennung in meinem Fall (PHP Framework) schneller mittels
SQL ist.

> Es existieren mehr als nur eine handvoll Kalender-Applikationen
> im Web,

Stimmt und ich habe mir schon einige angeschaut. Ich habe keine
Anwendung gefunden die 'unendliche Wiederholung' und
ueberlappungspruefung zugleich unterstuetzt. Der groesste Teil
unterstuezt 'unendliche Wiederholung'.

> Es gibt keinen Bezug zu Datenbanken

Weil sie nicht dafuer ausgelegt sind? Ich finde das das eine absolut
Datenbankrelatierte Frage ist (siehe 'Developing Time-Oriented Database
Applications in
SQL')..
Sobale ich eine funktionierende Struktur habe poste ich sie gerne!
Gruss,

Nikolai

Re: =?iso-8859-1?q?Re:_Unmögliches_Datenbank_Design=3F?

Hehe Christian,

> 'interessant' im Sinne von 'ich habe gerade nichts anderes zu tun als
> über etwas nachzudenken, was keinerlei praktische Bedeutung hat'?

Zumindest stelle ich eine Frage und schreibe nicht Antworten ohne
Loesungsansatz (hmm wer nutzt seine Zeit...)

> Weshalb diese plötzliche Beschränkung auf praktisch Relevantes?

Wo habe ich es beschraenkt?

Mein Punkt: Wenn ich 'frei definierbar' schreibe meine ich in etwa:
Ich unterstuetze xxx und wenn ich yyy auch unterstuetzen will muss ich
xxx nicht komplett neuschreiben.. Also:
Sicher ist Trinitatis ein interessantes Anwendungsbeispiel.
Wenn ich woechentliche Wiederholungen unterstuetze, dann kann ich das
System einfach erweitern sodass es auch jeden x. tag im Monat
unterstuetzt...

> So richtig unendlich finde ich das nicht.

Dann sei doch so freundlich und schreibe einen Loesungsansatz der
wirklich 'unendliche' Events unterstuetzt :)
Gruss,

Nikolai

Re: =?iso-8859-1?q?Re:_=?iso-8859-1=3Fq=3FRe: =3D3D=3D3Fiso-8859-1=3D3Fq=3D3FRe:_Unmögliches_Da

"Nikolai Onken" wrote:
>
>> Wiederholte Fragen nach Lösungen für unsinnige Problemstellungen
>> sind z.B. jenseits dieser Grenze.
>
> Ich finde diese Problemstellung absolut nicht unsinnig - vielleicht
> nicht richtig in diesem Forum, aber nach einer Loesung zu suchen die
> Ueberschneidungen in der Zukunft finden kann und gleichzeitig
> 'unendliche' Wiederholung unterstuetzt finde ich viel interessanter als
> 'Wo speichere ich am besten Inventarobjekte ab die nicht mehr im
> Inventar existieren' oder wie finde ich den Maximalwert einer Spalte :)

Für den einfachen Fall
a) Termin A beginnt in Slot a1 und wiederholt sich alle a2 Slots und
b) Termin B beginnt in Slot b1 und wiederholt sich alle b2 Slots

ist die Frage nach einer Terminkollision äquivalent zur Frage nach
Lösungen für die lineare diophantische Gleichung

a1 + a2*x = b1 + b2*y

Das ist ein triviales mathematisches Problem und - wie bereits gesagt -
gibt es entweder keine oder unendlich viele Lösungen. Nachzulesen bei
Wikipedia oder jedem einführenden Text zur Zahlentheorie.





>> Es existieren mehr als nur eine handvoll Kalender-Applikationen
>> im Web,
>
> Stimmt und ich habe mir schon einige angeschaut. Ich habe keine
> Anwendung gefunden die 'unendliche Wiederholung' und
> ueberlappungspruefung zugleich unterstuetzt.

Ob das wohl damit zusammenhängen könnte, daß das keine praxisrelevante
Anforderung ist?

>> Es gibt keinen Bezug zu Datenbanken
>
> Weil sie nicht dafuer ausgelegt sind?

Relationale Datenbanken sind per Definition für jede Art von Applika-
tion zumindest prinzipiell geeignet. Dein Problem ist, daß du den
dritten Schritt vor dem ersten tun willst. Zuerst brauchst du klar
definierte Anforderungen, was ein "Termin" in deiner Anwendung ist.
Dann kannst du dir Gedanken um eine passende Datenstruktur für dieses
Objekt machen, dann Gedanken darüber ob und wie du die Daten in eine
relationale Datenbank packst. Hier onTopic bist du erst mit dem dritten
Schritt.

> Ich finde das das eine absolut Datenbankrelatierte Frage ist (siehe
> 'Developing Time-Oriented Database Applications in SQL')..

Das ist kein Kriterium. Es gibt Bücher zu beliebig esoterischen Themen.


XL

Re: =?iso-8859-1?q?Re:_=?iso-8859-1=3Fq=3FRe: =3D3D=3D3Fiso-8859-1=3D3Fq=3D3FRe:_Unmögliches_Da

Hey Axel,

um die Diskussion wieder On Topic zu machen...
Nach den Anforderungen die ich beschrieben habe, ist folgende DB
Struktur sinnvoll?

events:

datetime_start
datetime_end
name
description
other_fields
event_rules_id


event_exceptions:

datetime_start
datetime_end
replacingperiod_datetime_start
replacingperiod_datetime_end
repeat_pattern
name
description
other_fields
event_rules_id

event_rules:

datetime_start
datetime_end (if NULL = never ending)
repeat_pattern
name
description
other_fields

Das heisst, das ich im Endeffekt die Verhandenen Termine in einem
bestimmten Zeitfenster in die Tabelle events schreibe (sagen wir fuer
die nachsten 2 Jahre)..
Die Tabellen event_exceptions und event_rules dienen also nur zur
Generierung der Tabelle.
Gruss,

Nikolai

Re: Unmögliches Datenbank Design?

Hi Nikolai

Nikolai Onken wrote:
> ich beschäftige mich immer noch mit Datenbanken und Kalendar
> Anwendungen..
> Ist es möglich eine Datenbank zu erstellen die:
> 1. Unendliche Wiederholung von Events unterstützt? (Jährlich, jeden
> 1. Mittwoch im Monat)
> 2. Query zur Abfrage von überlappenden Serien (Überschneidet sich
> diese Serie mit einer anderen? )
> Ich denke nicht das es Möglich ist, da man bei unendlicher Länge nie
> einen bestimmten Zeitraum bestimmen kann...

Unterscheide grundsätzlich zwischen Datenablage und -verarbeitung.
Ersteres wird bspw. mittels relationalen Datenbanksystem erledigt,
zweiteres normalerweise seitens einer Applikationssprache. Im
3-Tier-Konzept existiert noch die dritte Komponente 'Datenanzeige', die
wir hier aber gar nicht anschauen wollen.

Deine erste Frage lautet, wie du denn sich wiederholende Termine ablegen
kannst. Die Antwort kannst du aus jeder Terminkalender-Lösung
herauslesen. Die Informationen werden aufgeteilt in:

(1)
(2)

Zu (1) muss ich wohl nicht viel sagen, Beschreibung, Anfang/Ende, Notiz,
Alarm, Kategorie, etc.

Deine Frage richtet sich wohl eher nach (2): Hier solltest du wohl die
Zeiteinheit des Intervalls angeben (no repeat,hourly, daily, weekly,
monthly, yearly) und die Grösse (every 1, 2, 3, ...). Weiter muss ein
Ende definiert werden (als Anfang wird der Einzeltermin gesetzt). Du
kannst Ende NULL lassen, um unendliche Wiederholungen zu speichern.

> Was wäre die am dichtkommenste Lösung? Muss ich mich dann fundamental
> für ein System entscheiden in dem jeder Event ein Eintrag in einer DB
> ist, oder in welchem ich überlappende Serien nicht überprüfen kann
> aber unendlich wiederholende Events unterstütze?

Nun möchtest du gerne überlappende Events eruieren. Dazu wirst du nicht
drum herum kommen, die Daten in eine Applikationssprache auszulesen und
die zeitliche Folge zu simulieren. Oder zumindest jede Serie mit einer
anderen Serie zu überprüfen. Du kannst natürlich via SELECT-Statement
die gegenseitig zu überprüfenden Events dank konkretem Zeitpunkt stark
einschränken, so dass sich auch bei vielen in der DB vorhandenen Events
die Rechenzeit im realistischen Bereich bewegt. Achte darauf, dass sich
die Rechenzeit hier mit zunehmenden Events mind. quadratisch steigt.

Nun kannst du argumentieren, dass du die Applikation auf dem RDBMS
aufsetzen möchtest und via Stored Procedures oder in anderen RDBMS bspw.
via PL/SQL das Problem behandeln möchtest. In MySQL sind Stored
Procedures IMHO noch zu wenig brauchbar, um solche umfangreichen
Applikationen zu schreiben. In PL/SQL ist sowas sicher kein Problem. Für
zweiteres bist du aber in d.c.d.mysql tatsächlich falsch.

> Das ist doch das selbe wie die Unschärferelation oder?

Nein. Lies http://de.wikipedia.org/wiki/Unsch%C3%A4rferelation, um zu
erfahren, was eine Unschärferelation ist. Das hat mit dem hier
angesprochenen Thema nicht ein Deutsch was gemeinsam. Nur schon deshalb,
weil wir uns in der rein distinkten Mathematik befinden. Hier gibt's
keine Stochastik, sondern ausschliesslich exakte Mathematik.

Ich meine, dass ich deine Frage hiermit sehr klar beantwortet habe und
meine auch, dass du damit deine gewünschte Aufgabe erfüllen kannst.
Weitere Fragestellungen erachte ich deshalb als überflüssig.

HTH, Johannes

Re: Unmögliches Datenbank Design?

Hallo Johannes,

danke fuer deine Antwort!! Das macht es auf jeden Fall um einiges
deutlicher..
Ich denke, dass das Design was ich gepostet habe meine Anforderungen
erfuellt.
Die Frage ist wie ich die Daten auslese bzw. eruiere. - da muss ich
wahrscheinlich ausprobieren ob es schneller ist diese Auswertung auf
das RDBMS zu verlagern oder in der Applikation selbst durchzufueren..
Die Anzeige ist das geringste Problem..
Gruss,

Nikolai

Re: UnmöglichesDatenbank-Design?

Nikolai Onken wrote:

> Das war der einzige Weg den ich mir im Moment vorstellen kann um
> einfach zu berechnen, ob ein Event auf einen Bestimmten Tag faellt oder
> nicht..
> Naturelich suche ich im Endeffekt den Weg der mir erlaubt ein Event zu
> erstellen was z.B. jeden 1. Montag + Donnerstag im Monat wiederholt.
> Gibt is in SQL moeglichkeiten diese Patterns zu berechnen?

Ich habe mir mal eine ähnliche Aufgabe gestellt und bin damals zu dem
Schluß gekommen, daß das nicht geht.

Mein Kalender sammelt alle "Terminquellen" (einmalige Termine, Schichten
im Nebenjob, Geburtstage und sonstige Jubiläen und eben "allgemeine
regelmäßige Termine") in einer temporären Tabelle. Das geht aber nur,
wenn ich lediglich den angegebenen Monat als relevant ansehe.

Hier habe ich mir eine Tabelle definiert, die so aussieht:

CREATE TABLE `periodisch` (
`Datum` date NOT NULL default '0000-00-00',
`Start` time default NULL,
`Ende` time default NULL,
`Text` varchar(33) NOT NULL default '',
`Frequenz` int(11) NOT NULL default '0',
`Einheit` enum('DAY','MONTH','YEAR') NOT NULL default 'DAY',
`ListeTermine` varchar(33) NOT NULL default '',
PRIMARY KEY (`Datum`,`Text`(13))
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Lange nicht genutzt, deshalb mußte ich erstmal grübeln :-}

ListeTermine ist eine Angabe der relevanten Termine: so lautet eine Zeile
bspw.
Datum: 2004-01-02
Start: NULL
Ende: NULL
Text: Gelber Sack 2004
Frequenz: 14
Einheit: DAY
ListeTermine: 1:27

Zur gegebenen Zeit werden diese Informationen dann eingearbeitet, indem
alle in ListeTermine angegebenen Termine (könnte hier z.B. auch
1:10,12:17,19,21:27 lauten) in der temporären Tabelle "ausformuliert"
werden (applikationsseitig) und danach anhand eines Kriteriums
selektiert (z.B. aktueller Monat). Was besseres ist mir damals nicht
eingefallen, ob es nicht doch besser ginge, habe ich jetzt keine Muße,
zu überlegen.


Lange Rede, kurzer Sinn: Du kannst periodische Termine speichern. Auch
unendlich lange. Aber irgendwann - spätestens bei der Anzeige - mußt Du
"das Ende erkennen" - z.B. indem Du Dich aufs aktuelle Jahr beschränkst.

Zur Erkennung von Kollisionen beim Einfügen müßtest Du Dich AFAICS auf
das kgV der Tagesanzahl der beiden Frequenzeinheiten beschränken. Das
wird schwierig bei Mischung von täglichen/wöchentlichen Terminen
einerseits und monatlichen/jährlichen Terminen andererseits und geht
auch nur applikationsseitig.


Für unendliche Termine könnte man hier dann entsprechend hohe Werte
nehmen - für jährliche Ereignisse etwa 0:100.

HTH ein Stück weiter,


Thomas
--
Napoleon trug immer Rot, damit seine Soldaten nicht sehen konnten, wenn
er verwundet wurde. Die Nazis trugen braune Hosen... (unbekannte Quelle)

Re: Re: =?iso-8859-1?q?Re:_=?iso-8859-1=3Fq=3FRe: =3D3D=3D3Fiso-8859-1=3D3Fq=3D3FRe:_Unmögliche

"Nikolai Onken" wrote:
>
> um die Diskussion wieder On Topic zu machen...
> Nach den Anforderungen die ich beschrieben habe, ist folgende DB
> Struktur sinnvoll?

Nein.

> events:
>
> datetime_start
> datetime_end
> name
> description
> other_fields
> event_rules_id
>
>
> event_exceptions:
>
> datetime_start
> datetime_end
> replacingperiod_datetime_start
> replacingperiod_datetime_end
> repeat_pattern
> name
> description
> other_fields
> event_rules_id
>
> event_rules:
>
> datetime_start
> datetime_end (if NULL = never ending)
> repeat_pattern
> name
> description
> other_fields
>
> Das heisst, das ich im Endeffekt die Verhandenen Termine in einem
> bestimmten Zeitfenster in die Tabelle events schreibe (sagen wir fuer
> die nachsten 2 Jahre)..
> Die Tabellen event_exceptions und event_rules dienen also nur zur
> Generierung der Tabelle.

Ein Event ist ein eigenständiges Objekt und sollte getrennt von den
durch ihn belegten Timeslots gespeichert werden. Ebenso sollten die
Zeitspezifikationen für ein Event getrennt gespeichert werden (das ist
eine 1:n Relation).

CREATE TABLE event {
id INT PRIMARY KEY,
desc_short VARCHAR(30),
desc_long VARCHAR(255)
}

CREATE TABLE eventrule {
id INT PRIMARY KEY,
event_id INT REFERENCES event.id ON DELETE CASCADE,
time_start TIME,
time_end TIME,
date_start DATE NOT NULL,
date_end DATE,
type ENUM ('single', 'exception', 'daily', 'weekly', ...)
}

CREATE TABLE timeslot {
start DATETIME,
end DATETIME,
rule_id INT REFERENCES eventrule.id ON DELETE CASCADE,
event_id INT REFERENCES event.id ON DELETE CASCADE
}


Mit etwas Geschick kommt man mit wenigen Wiederholungspattern aus.
z.B. könnte man "jeden Montag und Mittwoch von 15:00-17:00 Uhr"
als *zwei* eventrules speichern, je eine für Montag und Mittwoch
mit type='weekly'.

Oben stehendes Schema kann keine Events erfassen, die Datumsgrenzen
überschreiten. Allerdings könnte man "von Montag 13:00 Uhr bis Freitag
9:00 Uhr" als 3 eventrules speichern. Ein 'single' Montag 13:00 bis
24:00, ein 'daily' von Dienstag bis Donnerstag, jeweils 0:00 bis 24:00
und ein 'single' für Freitag. Das Zusammenfassen von lückenlos
aneinanderstoßenden timeslots muß dann die Applikation erledigen.

Was noch fehlt, ist der Bezug auf einen Nutzer. Außerdem ist
timeslot.event_id eine (gezielte) Denormalisierung. Für den
typischen Anwendungsfall "zeige mir alle Termine für $ZEITRAUM"
muß man so nur timeslot und event JOINen. Ohne diese Spalte
müßte man auch eventrule in den JOIN aufnehmen.


XL

Re: =?iso-8859-1?q?Re:_=?iso-8859-1=3Fq=3FRe: =3D3D=3D3Fiso-8859-1=3D3Fq=3D3FRe:_Unmögliches_Da

Axel Schwenke schrieb:

> CREATE TABLE eventrule {
> id INT PRIMARY KEY,
> event_id INT REFERENCES event.id ON DELETE CASCADE,
> time_start TIME,
> time_end TIME,
> date_start DATE NOT NULL,
> date_end DATE,
> type ENUM ('single', 'exception', 'daily', 'weekly', ...)
> }
>

>
> Oben stehendes Schema kann keine Events erfassen, die Datumsgrenzen
> überschreiten.

Das ließe sich evtl. hinbekommen, wenn man 'duration' statt 'time_end'
speicherte.

Re: =?iso-8859-1?q?Re:_=?iso-8859-1=3Fq=3FRe: =3D3D=3D3Fiso-8859-1=3D3Fq=3D3FRe:_Unmögliches_Da

Bis jetzt ist mir noch nicht die Idee gekommen den Timeslot aus der
Eventtabelle zu nehmen und in eine eigene Tabelle zu stecken. Das macht
es viel Uebersichtlicher!
Weiterhin bin ich gespannt, was das Buch 'Temporal Data and the
Relational Model' fuer Ansaetze hat!
Ich muss aber sagen, dass nach dem Ueberfliegen von 'Developing Time
Oriented Database Applications in SQL' ich es sicher nicht Unsinnig
finde um ueber dieses Thema zu diskutieren! Loesungsansaetze sind
sicher nicht Trivial und eine Bedingung wie 'unendliche' Wiederholungen
ist denke ich auch nicht so unsinnig..
Seltsamerweise gibt es aber keine kommerzielle oder opensource temporal
datenbank (oder doch?)

Re: =?iso-8859-1?q?Re:_Unmögliches_Datenba

Nikolai Onken schrieb im Newsbeitrag
> Ich finde die Problemstellung interessant und einfach
> den Kalender bis 2099 zu begrenzen finde ich nicht
> interessant...

beim Jahr 2100 kann's aber interessant sein, denn evtl. haben da so
manche Betriebssysteme oder Programme ihre Probleme mit der
Gregorianischen Kalender. Du wirst auch feststellen, dass bei vielen
Armbanduhren die Aussage getroffen wird, dass der Kalender bis ins
Jahr 2099 reicht ... aber nicht weiter ;-)

So long,
-+- Dirk -+-

Re: Unmögliches Datenbank Design?

Nikolai Onken schrieb:
> Hallo,
>
> Ist es möglich eine Datenbank zu erstellen die:
>
> 1. Unendliche Wiederholung von Events unterstützt? (Jährlich, jeden
> 1. Mittwoch im Monat)
> 2. Query zur Abfrage von überlappenden Serien (Überschneidet sich
> diese Serie mit einer anderen? )
>

1. Ja, ist es!
2. Ja auch, ABER solltest Du zwei (oder mehr) unendliche Terminserien
miteinander vergleichen wollen wird dieser Vergleich mindestens genauso
lange dauern, denn es gibt ja unendlich viele Tage in der Zukunft die
dann miteinander verglichen werden müssten.

Fazit:
Eine Überprüfung auf Überschneidungen beim neu Anlegen eines
Termins/Terminserie auf die nächsten paar Monate ist vollkommen
ausreichend. Bei Einzelterminen und endlichen Terminserien wäre es
tatsächlich noch denkbar Überschneidungen (auch mit unendlichen Termin-
serien) festzustellen, denn es gibt einen festen Zeitraum der überprüft
werden muss.

MFG
Norbert