Datenbankdesign: wiederkehrende [Ereignisse] Aktionen

[Sir Rufo]

Zitat von jobo:

Wenn Deine Datenbank bit Arithmetik beherrscht oder Du den ganzen Kram im Client durchhechelst (Der kann ja bit Arithmetik), kann man damit wohl arbeiten.
Falls nicht und Du bspw. einen Report über die Schaltvorgänge der nächsten Stunden, Tage, Wochen liefern musst, sieht es vielleicht schon anders aus.

Wenn die Informationen ausreichend und eindeutig sind um die korrekten Schaltzeitpunkte zu ermitteln, dann kann auch ein Report erstellt werden (Reports basieren nicht zwangsläufig auf einer reinen SQL-Abfrage).

[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.

[Klaus01]

Zitat von Jumpy:

Wie würde(st) man / du, dann das Programm bzw. den Dienst machen, der das Starten der Geräte übernimmt?

..

Mir geht es darum, was mach der Dienst? Kreiert der sich aus der o.g. Tabelle dann einmal am Tag eine Aufgabenliste ggf. in einer Temp-Tabelle ala "was muss ich heute machen"? Und guckt dann jede Minute, ob er in der Minute was starten soll?

Oder "guckt" er in jeder Minute in der ursprünglichen Konfigurationstabelle, ob was zu starten ist?

Da die Daten in der Tabelle jederzeit von jedem geändert werden können, werde ich die Tabelle regelmäßig einlesen müssen.
Da ich vorhabe Zeiten nur in einem 5 Minuten Raster zuzulassen sollte es ausreichen die Tabelle alle 5 Minuten einzulesen.

Dann wie Sir Rufo geschrieben hat, die Aktionen ausführen die zwischen dem letzten (ausschliesslich) Auslesungszeitpunkt und dem jetzigen (einschliesslich) Zeitpunkt liegen.

Das macht der Dienst/Service.

Mit der Client_GUI kann jedes Gerät oder Gerätegruppen jederzeit ein- und ausgeschaltet werden.

Grüße
Klaus

[Jumpy]

Zitat von Klaus01:

Da die Daten in der Tabelle jederzeit von jedem geändert werden können, werde ich die Tabelle regelmäßig einlesen müssen.

Ja, das ist ein sinnvoller Hinweis. Da könnte das mit dem erstellen einer temporären Tabelle "was muss heute gemacht werden" schwer in die Hose gehen. Also lieber die Konfig-Tabelle jedes mal nach "jetzt" zu schaltenden Geräten zu prüfen.

Zitat von Sir Rufo:

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.

Stimmt. Darauf muss man ja auch achten, da man ja in der Regel sowas mit einem Timer oder so macht, der ja nicht so genau ist.

Danke.

[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

[jobo]

Wenn man ein Raster vorsieht und es bei der Eingabe auch -geführt- einhält, ist sowas doch unnötig,oder?
Ich muss dann nur am Raster entlang alles an oder abschalten, was dort definiert ist.
Ist das Raster lediglich ein Muster, also z.B. im Wochenrythmus, dann werden entsprechend später oder frische Einträge solange ausgeführt, bis der Rasterzeitpunkt erreicht ist, ansonsten dann wieder ne Woche später.

[nahpets]

Hallo Zusammen,

finde es interessant, das meine "Wochentagstabelle" zu einer "heißen" Diskussion führte.

Für den reinen technischen Ablauf ist sie irrelevant.
Für die Pflege per GUI und Nachschlagtabelle kann sie aber hilfreich sein.

Man kann ja hergehen und den Montag als 1 bis zum Sonntag als 7 definieren. Der Anwender sieht aus der Nachschlagtabelle nur die Tagesbezeichnungen. Die kann man in der Tabelle natürlich in beliebige andere Sprachen übersetzen. Dies hat auf das System keine technischen Auswirkungen, dieses funktioniert ohne irgendeine Änderung weiter. Natürlich könnte man die Tage auch mit 'Apfel', 'Birne'... bezeichnen, Hauptsache ist, der Anwender weiß, was gemeint ist.

Aber mit dieser Tabelle funktioniert auch die Übersetzung dieser Werte:

Code:

Montag :    1  [1000 0000]
Dienstag:   2
Mittwoch:   4
Donnerstag: 8
Freitag:   16
Samstag:   32 
Sonntag:   64  [0000 0010]

Über eine Nachschlagtabelle kann man halt beliebige technische Schlüssel, die für den Anwender irrelevant sind, in die für den Anwender relevante Bezeichnung übersetzen.

Natürlich ist im Programm eine Abfrage der Formif Day = Monday then einfacher zu lesen als if Day = 1 then . Aber wenn der Anwender nun Montag eingibt, muss ich dann das Programm ändern auf if Day = Montag then ? Wenn nein, woher weiß das Programm, dass Monday gleichbedeutend mit Montag ist? Also muss es auch hier irgendwo im System dafür eine "Übersetzung", eine Vereinbarung geben. Irgendwo muss es also passieren, dass der Wert in Day mit dem Wert von Monday übereinstimmt, auch dann, wenn der Anwender in der Oberfläche eventuell Montag eingegeben haben sollte.

Gut, hier haben wir einen Konflikt zwischen Englisch und Deutsch, man kann von einem Programmierer erwarten, dass er versteht, was gemeint ist. Aber was ist, wenn die Anwender die Tagesnamen nun in Spanisch, in Griechisch, in Türkisch oder Arabisch, in Indisch... eingeben sollen, oder gar bei der Sprache freie Auswahl haben? Solange ein Wochentag sprachunabhängig immer in den gleichen technischen Wert übersetzt wird, geht das problemlos und ist für die technische Umsetzung transparent.

Ja, ich nutze gerne die dritte Normalform und arbeite in Programmen und der Datenbank möglichst nur mit den technischen Schlüsseln. Der Anwender bekommt, sei es in der GUI oder in Reports, nur die verbalen Bezeichnungen zu den technischen Schlüsseln zu sehen. Änderungen der verbalen Bezeichnungen haben dann keinen Einfluss auf die Funktionalität des technischen Teiles eines Systemes.

Die Wochentagstabelle war ja nur als ein möglicher Ansatz gedacht. man könnte sie ja auch noch ergänzen mit z. B.

Code:

WochenTagTabelle
ID,Tag
1,Montag,
2,Dienstag,
...
7,Sonntag
8,Samstag und Sonntag
9,Montag bis Freitag
10,gesetzlicher Feiertag
11,Frühlingsanfang
12,Karfreitag
...

Es ist alles eine Vereinbarungssache ob und wie weit man ein System normalisiert.

Bei den Wochentagen mit ihren gerade mal 7 möglichen Werten erscheint ein derartiges Vorgehen eher absurd. Nehmen wir aber mal ein System aus dem Gesundheitswesen, bei dem, abhängig von einem verletzten Körperteil, eine bestimmte Behandlung, Berechnung... ausgelöst werden soll.
Dann hat man da einen Wert für den Kopf, einen für die Nase, einen für einen Fuss, und zusätzlich einen Wert für links oder rechts, desgleichen für Arme, Bein, Daumen, Elle, Rippen und Wirbel der Brustwirbelsäule, der Lendenwirbelsäule, ... dazu dann noch einen Wert für Bruch, Verstauchung, Verbrennung, ...
Über Nachschlagtabellen läßt sich hier eine anwenderfreundliche GUI erstellen, in Reporten können die passenden Texte ausgegeben werden, technisch wird aber nur mit den Schlüsselwerten gearbeitet.

Es gibt dann keine Abfrage in der Form

Delphi-Quellcode:

if Körperteil = Fuß then begin
  if Körperseite = links then begin
  ...
  end else if Körperseite = rechts then begin
  ...
  end else begin // je nach Körperteil...
  ... Den linken bzw. rechten Kopf gibt es ja nicht ;-)  
  end; 
end;
...

Nachschlagtabellen für Bezeichnungen haben halt den Vorteil, dass Bezeichnungsänderungen keinerlei Einfluss auf die Funktionalität eines Systemes haben.

Natürlich ist es beim Systemdesign entscheidend, sich Gedanken darüber zu machen, ob dieses Vorgehen sinnvoll und notwendig ist oder ob man es da nicht übertreibt.

Es ist also eine Vereinbarungssache.

Und hier war ja nur nach Vorschlägen gefragt und kein perfektes Design, für den rudimentär beschriebenen Sachverhalt, gefordert

[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

[Klaus01]

Zitat von p80286:

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

.. da hätte aus meiner Sicht auch den Nachteil das Geräte auch vor dem gesetzten Termin (nicht lange davor) abgeschaltet werden.
Das könnte eventuell den einen oder anderen überraschten Nutzer zu Folger haben.

Grüße
Klaus

[Mikkey]

[QUOTE=Sir Rufo;1242705][QUOTE=p80286;1242656]

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).