Hallo,

ich habe ein bisschen ein Problem, wo ich nicht so recht weiß, wie ich es angehen soll.

Ich versuche es mal zu beschreiben:

Wir haben Vorgänge, die an einem bestimmten Datum starten und eine Mindestlaufzeit von x Tagen haben. Daraus folgt, der Vorgang kann vom Benutzer frühestens am Startdatum + x Tage beendet werden.
Nun haben wir zu den Vorgängen Ereignisse an einem bestimmten Datum, die selbst eine Mindestlaufzeit haben. Damit kann es sein, dass, ausgelöst durch ein Ereigniss, der Vorgang länger laufen muss, bis es frühestens vom Benutzer beendet werden kann.

Durch meinen Vorgang (Datum + Mindestlaufzeit) und den Ereignissen zum Vorgang (auch Datum + Mindestlaufzeit), kann ich ausrechnen, wann ein Vorgang FRÜHESTENS beendet werden kann.

Nun habe ich einen Kalender, der nur einen bestimmten Datumsausschnitt zeigt (z.B. eine Woche). In diesem Kalender soll ich nun informativ anzeigen, welche Vorgänge an einem Datum beendet werden könnten. Das heißt, ich brauche eine Funktion, die mit in einem gegebenen Zeitraum die frühesten Endtermine ausgibt.

1. Idee: Ich könnte natürlich zu allen Vorgängen beim Anzeigen im Kalender den frühesten Endtermin immer wieder ausrechnen und wenn es im Zeitraum liegt, dann anzeigen. Aber da die Vorgänge immer mehr werden, wird diese Funktion mit mehr Daten immer langsamer -> ist also Mist.

2. Idee: Ich könnte auch den frühesten Endtermin beim speichern der Vorgänge und Ereignisse ausrechnen und in einer Tabelle speichern. Beim Anzeigen muss ich dann nur diese Tabelle abfragen. Dann habe ich eine Redundanz in der Datenbank. Sowas mag ich eigentlich überhaupt nicht.

Wie würdet ihr das Problem lösen? Ich tendiere im Moment zur 2. Idee, habe dabei aber etwas Bauchschmerzen, weil ich dann Daten mit den Endterminen in der Datenbank vom Programm pflegen lassen muss. Aber bei der ersten Idee sehe ich in Zukunft Performanceprobleme.

Danke!
Jens

Hi Jens,

würde auch eher deine 2te Idee umsetzen, da alles andere auch meiner Meinung nach auf Dauer zu Performanceproblemen führt.
Die Daten in der 'neuen' Tabelle könnten ja evtl. auch statt vom Programm von einem DB-Trigger gepflegt werden ? Schon mal in der Richtung nachgedacht ?

so ala: wenn Post in Tabelle 1, dann bissl rechnen und Tabelle 2 updaten ? Somit verlagerst du Pflege und Last auf den Server und brauchst bei Auswertung wirklich nur die 'neue' Tabelle abfragen

Hi zuma,
Danke für die Antwort!

zuma hat folgendes geschrieben :

Hi Jens, würde auch eher deine 2te Idee umsetzen, da alles andere auch meiner Meinung nach auf Dauer zu Performanceproblemen führt. Die Daten in der 'neuen' Tabelle könnten ja evtl. auch statt vom Programm von einem DB-Trigger gepflegt werden ? Schon mal in der Richtung nachgedacht ? so ala: wenn Post in Tabelle 1, dann bissl rechnen und Tabelle 2 updaten ? Somit verlagerst du Pflege und Last auf den Server und brauchst bei Auswertung wirklich nur die 'neue' Tabelle abfragen

Ja, in einem Trigger, oder auch im Programm selbst, ist bei meiner Anwendung fast egal. Wird sowieso in 80% der Fälle nur als Einzelplatzanwendung benutzt. Dann läuft derr Server auch auf dem Arbeitsplatz. Leute, die das Programm im Netzwerk nutzen, haben wir selten. Und wenn, dann mit höchstens 2-3 Arbeitsplätzen. Aber ich würde das Programm selbst schlanker halten. Das hat auch Vorteile.

Gruß,
Jens

Hi,

Nersgatt hat folgendes geschrieben :

1. Idee: Ich könnte natürlich zu allen Vorgängen beim Anzeigen im Kalender den frühesten Endtermin immer wieder ausrechnen und wenn es im Zeitraum liegt, dann anzeigen. Aber da die Vorgänge immer mehr werden, wird diese Funktion mit mehr Daten immer langsamer -> ist also Mist. 2. Idee: Ich könnte auch den frühesten Endtermin beim speichern der Vorgänge und Ereignisse ausrechnen und in einer Tabelle speichern. Beim Anzeigen muss ich dann nur diese Tabelle abfragen. Dann habe ich eine Redundanz in der Datenbank. Sowas mag ich eigentlich überhaupt nicht.

eine Frage: hängt die Berechnung des Endtermins nur von dem einen Vorgang und den zugehörigen Ereignissen ab? Oder ändert sich der Termin abhängig von der Anzahl der Vorgänge?
Im ersten Fall spricht nichts dagegen den Termin fix in der DB zu speichern, da er ja ein fixes Merkmal des Vorgangs ist. Im zweiten Fall bleibt Dir eh nichts anderes übrig, als die Termine immer wieder zu berechnen dann erst zu entscheiden, ob sie angezeigt werden müssen.


Grüße,
Uli

Nö, ein Vorgang ist mit seinen Ereignissen eine abgeschlossene Einheit. Ein Vorgang hängt nicht von anderen Vorgängen ab.

Dann würde ich den Termin speichern. In dem Fall wiegt Perfomance wohl mehr als puristisches DB Design

Uli

Dann werde ich es wohl so machen, dass ich den Termin speichere, denn etwas besseres fällt mir nicht ein. Danke für die Antworten.