Datenbankdesign: wiederkehrende [Ereignisse] Aktionen

**Sir Rufo**

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.

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

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:

markieren

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.

markieren

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

markieren

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

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

**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?

**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