Datenbankdesign: wiederkehrende [Ereignisse] Aktionen

[Sir Rufo]

[QUOTE=Mikkey;1242714][QUOTE=Sir Rufo;1242705]

Zitat von p80286:

Zitat von Sir Rufo:

Bei meiner Vorgehensweise ist diese Vereinbarung zum Redaktionsschluß hinfällig

führt allerdings auch dazu, dass ggfs. Nutzer überrascht werden, dass der eigentlich erst für morgen geplante Job bereits heute ausgeführt wird (z.B. 2 Minuten nach dem Termin eingegeben).

Dann ist daran aber dein Taktgeber oder Systemzeit schuld

[Mikkey]

Zitat von Sir Rufo:

Zitat von Mikkey:

Zitat von Sir Rufo:

Bei meiner Vorgehensweise ist diese Vereinbarung zum Redaktionsschluß hinfällig

führt allerdings auch dazu, dass ggfs. Nutzer überrascht werden, dass der eigentlich erst für morgen geplante Job bereits heute ausgeführt wird (z.B. 2 Minuten nach dem Termin eingegeben).

Dann ist daran aber dein Taktgeber oder Systemzeit schuld

Hiermit:

...
Abfrage 15:00
Abfrage 15:05
Abfrage 15:10
...

Der Benutzer erstellt um 15:04 einen täglichen Termin für 15:02

Du stellst um 15:05 fest, dass Du diesen Eintrag berücksichtigen musst, da Du ihn um 15:00 nicht berücksichtigt hast.


Oder habe ich an

Zitat von Sir Rufo:

Dann werden alle Einträge geprüft, ob diese im Zeitraum zwischen dem letzen Zeitpunkt und dem aktuellen Zeitpunkt ausgelöst werden mussten

etwas falsch verstanden?

[Sir Rufo]

@Mikkey

In diesem konkreten Fall ja, denn eine Überprüfung im Intervall von 5 Minuten macht nur Sinn, wenn auch nur Schaltzeitpunkte im 5 Minuten-Raster erlaubt sind.

Somit kann dein Eintrag so gar nicht eingetragen werden.

Dauert allerdings die Abfrage und Signalisierung länger als das Zeitintervall (hier 5 Minuten), dann kann es durchaus zu solchen Überschneidungen kommen. Dann stimmt aber mit dem System etwas nicht.

Eine mögliche Zeitspanne in der das von dir beschriebene Szenario auftauchen könnte, ist die Zeitspanne zwischen dem Bemerken (ah, ich muss mal nachschauen) und dem Absetzen der Abfrage.

Diese Zeitspanne sollte vernachlässigbar klein sein (wir sprechen von Millisekunden, denn eine Abfrage- bzw. Einfügeoperation erfolgt innerhalb einer Transaktion und die ist ACID).

Die Abfrage mit der Zeitspanne ist allerdings auch nur dafür da, die Schaltzyklen gesichert auszuführen, falls das System mal für mehr als 5 Minuten (Taktintervall) blockiert ist. Dann würde mich das nicht stören, oder man baut einen Mechanismus mit ein, der das unterbindet. (Einfach zum Datensatz den Zeitpunkt der Änderung/Erstellung speichern).

Probleme muss man lösen und nicht größer reden als diese sind

[nahpets]

@Mikkey
Nein, Du hast da nichts falsch verstanden, dass von Dir genannte Problem kann auftreten.

Fraglich ist nur: Wenn alle 5 Minuten abgefragt wird, ob irgend etwas zu machen ist, so sind Termine innerhalb dieses Zeitraumes nicht zwingend zielführend.

Wie soll ein Gerät um 15:02 gestartet oder ausgeschaltet werden, wenn die Abfrage um 15:00 Uhr und um 15:05 Uhr ausgeführt und der Schaltvorgang veranlasst wird.

Bei einem vereinbarungsgemäßen Steuerinterval von 5 Minuten dürfen auch nur Termine erfasst werden, die diesem 5-Minutenraster entsprechen.

Andernfalls müsste die Vereinbarung lauten:

Starte oder stoppe das Gerät zum nächstmöglichen Zeitpunkt, der gleich oder größer als der erfasste Termin ist.

[Mikkey]

Zitat von Sir Rufo:

Somit kann dein Eintrag so gar nicht eingetragen werden.

Damit haste natürlich Recht.

Zitat von Sir Rufo:

Diese Zeitspanne sollte vernachlässigbar klein sein (wir sprechen von Millisekunden, denn eine Abfrage- bzw. Einfügeoperation erfolgt innerhalb einer Transaktion und die ist ACID).

Es kommt dabei auf die Implementierung an, wenn dazu jeweils die DB-Verbindung initiiert wird, mag es sich auch im Sekundenbereich abspielen.

In dem Fall dürfte mein Benutzer aber nicht überrascht sein, da er ja für den Job die aktuelle Uhrzeit eintragen müsste.

[p80286]

Zitat von Sir Rufo:

Zitat von p80286:

Zitat von Sir Rufo:

@Jumpy

Die beste Vorgehensweise ist folgende:

Man merke sich bei jedem Durchlauf den aktuellen Zeitpunkt.
Dann werden alle Einträge geprüft, ob diese im Zeitraum zwischen dem letzen Zeitpunkt und dem aktuellen Zeitpunkt ausgelöst werden mussten und triggert diese dann.

Ich würde das anders herum angehen, Du liest zum Zeitpunkt x alle zukünftigen Aktionen (der nächsten 5,10 Minuten) und arbeitest diese dann ab.

Wobei eine wesentliche Vereinbarung wäre , wann ist "Redaktionsschluß". Sprich die Eingabe einer Aktion muß mindestens z Sekunden/Minuten vor Ausführungszeitpunkt erfolgen.

Gruß
K-H

Bei meiner Vorgehensweise ist diese Vereinbarung zum Redaktionsschluß hinfällig

Dafür arbeitest Du aber die Vergangenheit auf, was mir nicht so behagt.
Da es sich aber um ein 5 Minuten Raster handelt sind die Auswirkungen in der Praxis wohl vernachlässigbar, man muß nur wissen, das jedes Vorgehen Vor- und Nachteile hat.

Zitat von nahpets:

Wie soll ein Gerät um 15:02 gestartet oder ausgeschaltet werden, wenn die Abfrage um 15:00 Uhr und um 15:05 Uhr ausgeführt und der Schaltvorgang veranlasst wird.

Ich habe den Ablauf so verstanden, daß um 15.00 Uhr gefragt wird was in den nächsten 5 Minuten zu tun ist, und das wird dann abgearbeitet. Ein Schaltvorgang um 15:02 sollte da durchaus bekannt und ausführbar sein. Ggf. wird das Abfrageintervall auf 60sec,30sec.. verkürzt.

Gruß
K-H

[nahpets]

Zitat von p80286:

Zitat von nahpets:

Wie soll ein Gerät um 15:02 gestartet oder ausgeschaltet werden, wenn die Abfrage um 15:00 Uhr und um 15:05 Uhr ausgeführt und der Schaltvorgang veranlasst wird.

Ich habe den Ablauf so verstanden, daß um 15.00 Uhr gefragt wird was in den nächsten 5 Minuten zu tun ist, und das wird dann abgearbeitet. Ein Schaltvorgang um 15:02 sollte da durchaus bekannt und ausführbar sein. Ggf. wird das Abfrageintervall auf 60sec,30sec.. verkürzt.

Schon klar, aber wir müssen uns dann bewusst sein, dass die durchschnittliche Abweichung (bei einem Abfrageraster von 5 Minuten) zwischen dem erfassten Termin und der tatsächlichen Ausführung bei +/- 2,5 Minuten liegt dürfte.
Wenn es eine entsprechende Vereinbarung gibt, ist das ok.

Soll es aber eine Ablaufsteuerung geben, bei der die Reihenfolge zu beachten ist, wird es doch eventuell etwas schwieriger. Dann muss eine präzisere Vorgabe, Terminerfassung und/oder Ablaufsteuerung her.

Für ein "vernünftiges" Design benötigen wir mehr Informationen zum umzusetzenden System. Momentan sind noch zuviele Unwägbarkeiten und Interpretationsmöglichkeiten vorhanden.