Datenbankdesign: wiederkehrende [Ereignisse] Aktionen

[Klaus01]

Hallo,

in einer Tabelle habe ich mehrere Geräte eingetragen.

Diese Geräte sollen Wochentags (Mo - Fr) zu einem bestimmten Zeitpunkt (5 Minuten Raster) ein- und ausgeschaltet werden.

z.B. Mo-Fr: Einschalten: 08:00 Ausschalten: 17:30

Während des Wochenendes sollen die Geräte zu anderen Zeitpunkten geschaltet werden - oder komplett ausgeschaltet bleiben.

Wie würdet Ihr das Datenbankdesign anlegen?

Der Gerätetabelle noch zusätzliche Spalten spendieren
z.B:
Wochetags_einschalten
Wochetags_ausschalten
Wochenende_einschalten
Wochenende_ausschalten

Oder eine seperate Tabelle mit den Zeitdaten und Verweis auf die GeräteID?

Oder gibt es noch einen anderen Ansatz?

Ich stehe etwas ratlos da.


Grüße
Klaus

[haentschman]

Moin...8-)
definitiv:

Zitat:

Oder eine seperate Tabelle mit den Zeitdaten und Verweis auf die GeräteID?

:thumb:

[BUG]

Um das Ganze relativ flexibel zu machen, könnte die zusätzliche Tabelle so aussehen:
Zwei Zeitstempel geben dann jeweils einen Zeitpunkt relativ zu 0:00 des Tages an (von .. bis). Jedes Gerät, für das es einen Tabelleneintrag gibt, der den aktuellen Zeitpunkt einschließt, wird zu dieser Zeit aktiviert. Zusätzlich hast du eine Maske*, welche bestimmt, für welche Tage die Regel bestimmt ist.
Das entscheidende Detail bei diesem Ansatz ist: Jedes Gerät kann mehrere Regeln besitzen, die an unterschiedlichen Tagen das Gerät anschalten.

* z.B. ein Bitfeld oder einzelne boolesche Spalten; entweder für Werktags/Wochenende oder Mo..So.
Mich würde es nicht wundern, wenn irgendwann kurzfristig der Bedarf besteht, einzelne Wochentage voneinander zu unterscheiden. In der Datenbank und der Logik könnte man das schon anlegen.

[p80286]

Ich würde es so machen:

• ID
• Gerät_ID
• AktionsTyp (an/aus)
• AktionsZeitpunkt

Da bist Du ganz frei in der Definition der Zeitspanne. Für Ein/Aus brauchst Du zwar 2 Datensätze aber Ein und Ausschalten sind ja auch zwei Aktionen.

Gruß
K-H

[Der schöne Günther]

Handelt es sich jetzt hierbei eigentlich um Regeln oder ganz strikt von extern immer wieder neu vorgegebene Ereignisse?

[nahpets]

Der Versuch eines Ansatzes:

Code:

Gerätetabelle
GeräteID,Name,Bezeichning,...
1,Staubsauger,

WochenTagTabelle
ID,Tag
1,Montag,
2,Dienstag,
...
7,Sonntag


UhrzeitTabelle
ID,WochenPlanID,Uhrzeit
10,1,10:00
...
20,2,15:00
...
30,3,17:00
...
40,4,09:00
...
50,4,08:00
...
60,5,15:00
...
70,6,12:00
...
80,1,11:00
...
90,1,17:15
...


TerminTabelle
ID,GeräteID,WochenTagID,UhrzeitID
1,1,1,10
2,1,2,20
...
9,1,6,70

Staubsauger startet demnach
Montag   10:00
Dienstag 15:00
Samstag  17:15


oder

TerminTabelle
ID,GeräteID,WochenTagID
1,1,1
2,1,2
...
9,1,6


Staubsauger startet zu allen Uhrzeiten, die sich zum Wochentag der Wochentagtabelle
in der Tremintabelle finden lassen.

Sofern (technisch) erforderlich (wie von p80286 angeregt) auch einen Ausschaltzeitpunkt oder eine Dauer für den Betrieb in Minuten, Sekunden... ab der Uhrzeit.

Code:

UhrzeitTabelle
ID,WochenPlanID,Uhrzeit,Dauer
10,1,10:00,00:05:00
...
20,2,15:00,00:15:00
...
90,1,17:15,00:00:05
...

oder

Code:

UhrzeitTabelle
ID,WochenPlanID,Uhrzeit,Typ (1 = ein, 0 = aus)
10,1,10:00,1
11,1,10:05,0
...
20,2,15:00,1
21,2,15:15,0
...
90,1,17:15,1
91,1,18:00,0
...

[BUG]

Zitat:

Zitat von p80286 (Beitrag 1242599)

Für Ein/Aus brauchst Du zwar 2 Datensätze aber Ein und Ausschalten sind ja auch zwei Aktionen.

Das ist auch eine Frage der gewünschten Abstraktionsebene. Ich finde es sinnvoll, die Planung/Regeln in der Datenbank zu speichern und bei Bedarf (oder regelmäßig) eine Ereignisfolge zu generieren, die dann abgearbeitet wird. Wenn man nur eine Ereignisfolge hat, könnte es (bei komplexeren Problemen) dann schwer werden, daraus die Überlegung/Planung zu rekonstruieren, die dazu geführt hat (z.B. um Fehler zu finden oder Pläne zu ändern).

[Sir Rufo]

Das sollte eigentlich reichen. Die Wochentage als ID-Tabelle ist überflüssig :)
Geräte

ID	Name
1	Gerät 1
2	Gerät 2

Wochenplan

ID	Gerät_ID	Tag	Uhrzeit	OnOff	Von	Bis
1	1	1	07:00	On
2	1	1	08:00	Off		31.12.2013
3	1	1	09:00	Off	01.01.2014
4	1	2	12:00	On
5	1	2	15:00	Off

Terminplan

ID	Gerät_ID	Datum	Uhrzeit	OnOff
1	1	01.01.2014	07:00	On
2	1	03.01.2014	08:00	Off

[nahpets]

Zitat:

Zitat von Sir Rufo (Beitrag 1242609)

Die Wochentage als ID-Tabelle ist überflüssig :)

und worher weißt Du, was für ein Wochentag 1 ist?
Sonntag oder Montag?

Bin es halt seit Jahrzehnten gewohnt für jeden Schlüsselwert (wie es hier der Tag ist) gibt es eine Tabelle, in der man die Bedeutung des Schlüsselwertes nachlesen kann.
Sicher kann man technisch gesehen hier auf diese Tabelle verzichten, ebenso, wie man technisch beim Gerät auf den Namen verzichten könnte. Der Informationsgehalt eines Steuersystemes wird hierdurch aber doch sehr eingeschränkt.
Wenn man mehrere Geräte mit gleichem Typ und oder Name... hat, so könnte man hier anstelle der Namen beim Gerät auch einen Fremdschlüssel auf eine Tabelle verwenden, in der alle Gerätetypen mit ihren Detaildaten enthalten sind.
Die Frage ist halt, wie weit man es mit der Normalisierung der Daten treibt.

[Klaus01]

Zitat:

Zitat von Der schöne Günther (Beitrag 1242600)

Handelt es sich jetzt hierbei eigentlich um Regeln oder ganz strikt von extern immer wieder neu vorgegebene Ereignisse?

.. gut, da ist die Überschrift etwas daneben, richtiger sind es immer wiederkehrende Aktionen.
Die Zeitstempel werden vom Benutzer konfiguriert (per GUI) und in die Datenbank geschrieben.
Ein Service liest die Daten aus der Tabelle und führt dann die Schaltaktion aus.

Zitat:

Zitat von BUG

Um das Ganze relativ flexibel zu machen, könnte die zusätzliche Tabelle so aussehen:
Zwei Zeitstempel geben dann jeweils einen Zeitpunkt relativ zu 0:00 des Tages an (von .. bis). Jedes Gerät, für das es einen Tabelleneintrag gibt, der den aktuellen Zeitpunkt einschließt, wird zu dieser Zeit aktiviert. Zusätzlich hast du eine Maske*, welche bestimmt, für welche Tage die Regel bestimmt ist.
Das entscheidende Detail bei diesem Ansatz ist: Jedes Gerät kann mehrere Regeln besitzen, die an unterschiedlichen Tagen das Gerät anschalten.

Werde ich drüber nachdenken.

Derzeit habe ich nur zwei Wochenteile (Wochentags und Wochenende).
Wenn ich das flexibel halten soll (was ja erstmal nicht schlecht ist) könnten
bei der Erstellung der Datensätze des Wochentags - Tageseinträge von 1 bis 5 erstellt werden.


@Sir Rufo
auf einen Wocheplan (mit Datum) und Terminplan wollte ich eigentlich nicht hinaus.

Es würde dann auf eine Tabelle hinauslaufen wie von p80286 vorgeschlagen.
Auch die von nahpets geht in diese Richtung.

Danke für die rege Beteiligung.

Grüße
Klaus

[Sir Rufo]

Zitat:

Zitat von nahpets (Beitrag 1242614)

Zitat:

Zitat von Sir Rufo (Beitrag 1242609)

Die Wochentage als ID-Tabelle ist überflüssig :)

und worher weißt Du, was für ein Wochentag 1 ist?
Sonntag oder Montag?

Woher weiß mann, dass mit 17:00 auch 17:00 MEZ gemeint ist?
Und in Delphi selber wird die Uhrzeit als Extended gehalten, woher weiß man, dass damit überhaupt eine Uhrzeit gemeint ist?

Das sind alles Vereinbarungen, die man trifft. Zudem die Datenbank auch über das Programm gefüllt wird.

So kann auch vereinbart sein, dass der Wert binär zu interpretieren ist (pro Tag ein Bit)

Zitat:

Zitat von Klaus01 (Beitrag 1242619)

auf einen Wocheplan (mit Datum) und Terminplan wollte ich eigentlich nicht hinaus.

Das Datum im Wochenplan ist nur dafür da einen gültigen Zeitraum zu definieren, aber den kann man auch weglassen.

[bernau]

@nahpets: Ich will dir nicht zu nahe treten, aber kennst du das Sptrichwort "Mit Kanonenkugeln auf Spatzen schießen".

Warum eine Wochentagstabelle? Wie Sir Rufo schon schrieb: Es muss vereinbart werden. Anonsten könnte man ja auch sagen, warum Deutsche Wochentage und nicht englische Bezeichnungen.

Warum eine Extra "UhrzeitTabelle" verwenden? Ist doch viel Besser, wenn die Zeit in die "TerminTabelle" statt einer ID geschrieben.

Wieviel Tabellen erzeugst du eigendlich, wenn es um komplexe Daten geht?


Das Beispiel von p80286 bring es "einfach" auf den Punkt.


Nur so meine Meinung.

[Furtbichler]

Zitat:

Zitat von nahpets (Beitrag 1242614)

Zitat:

Zitat von Sir Rufo (Beitrag 1242609)

Die Wochentage als ID-Tabelle ist überflüssig :)

und worher weißt Du, was für ein Wochentag 1 ist?
Sonntag oder Montag?

Das ergibt sich aus ISO 8601

Zitat:

...für jeden Schlüsselwert (wie es hier der Tag ist) gibt es eine Tabelle, in der man die Bedeutung des Schlüsselwertes nachlesen kann.

Vorsicht. Nur weil da dann 'Sonntag' steht, ist noch lange nicht klar, das das ein Sonntag ist. Was Du machst, ist eine 'Lookuptabelle' oder 'Ausprägung' eines Wertes. Bei Dir wird die Zahl 7 als Text 'Sonntag' abgebildet. Du könntest da auch 'Apfel' eintragen.

In diesem speziellen Fall würde ich die Wochentagsbezeichnung aus der CultureInfo des Rechners auslesen, weil ich annehme, das diese auch im ISO-Format abgelegt sind. Damit hätte ich sofort eine lokalisierte Ausprägung. Ähnlich würde ich mit den Monaten verfahren.

[Lemmy]

Guten Morgen,

@bernau/SIr Rufo:

Vereinbarungen sind schön und gut - aber warum sollte man denn beim Programmieren dann so was umständliches wie Enums und Konstanten verwenden? ein 1..3 für ja, nein, vielleicht reicht doch auch? ;-)

Es ist schlicht ne Frage wo Businesslogik abgelegt ist. Wenn die größtenteils in der DB steckt, z.b. weil man über ein ORM darauf zugreift und daher auch Enumdefinitionen in der DB braucht, dann hat man halt einige DB-Tabellen mehr. Insofern ist es eben nicht abwägig für die Wochentage eine Tabelle anzulegen - gerade auch um darüber Übersetzungen zu ermöglichen...

[bernau]

Zitat:

Zitat von Lemmy (Beitrag 1242637)

Guten Morgen,

@bernau/SIr Rufo:

Vereinbarungen sind schön und gut - aber warum sollte man denn beim Programmieren dann so was umständliches wie Enums und Konstanten verwenden? ein 1..3 für ja, nein, vielleicht reicht doch auch? ;-)

Es ist schlicht ne Frage wo Businesslogik abgelegt ist. Wenn die größtenteils in der DB steckt, z.b. weil man über ein ORM darauf zugreift und daher auch Enumdefinitionen in der DB braucht, dann hat man halt einige DB-Tabellen mehr. Insofern ist es eben nicht abwägig für die Wochentage eine Tabelle anzulegen - gerade auch um darüber Übersetzungen zu ermöglichen...

Wie Furtbichler schon sagte, es könnte statt Montag auch Apfel drin stehen oder Monday oder Lunes oder Trallala. Der Computer weis damit immer noch nicht, ob es ein Montag ist. Man muss es definieren. Somit wäre solch eine Tabelle nur für die Mehrsprachigkeit interessant.

[jobo]

Komische Diskussion.
Viele der führenden Anbieter eines RDBMS bieten Datumsarithmetik inkl. Wochentag nach ISO. Ich kann also aus einem Wochentag "Montag" eine Nr. berechnen, eine ID erhalten, mögliche Datumse eingrenzen und umgekehrt aus jedem Datum einen Wochentag ableiten.
Mit einer Tabelle, in der Zeitstempel, Muster nach Wochentag abgelegt sind, habe ich also höchste Freiheitsgrade und die Möglichkeit, mein Programmverhalten dynamisch anzupassen bzw. mit anderen Systemen zu harmonisieren.
Alle diese Daten und Funktionen kann ich natürlich auch "für mich allein " in der Anwendung berechnen und verwalten. In einer heterogenen Programmwelt macht das aber nur bedingt Sinn und kostet mehr Entwicklungszeit.

[Furtbichler]

Was nahpetS da gemacht hat, nennt sich 3NF. Kann man so machen, muss man aber nicht. ("Spatzen fliegen auch weg, wenn man sich pazifistisch nähert")

Zitat:

Zitat von Lemmy (Beitrag 1242637)

Insofern ist es eben nicht abwägig für die Wochentage eine Tabelle anzulegen

Richtig. Aber damit ist die Semantik ja nicht geklärt. (PS: "abwegig")

Zitat:

- gerade auch um darüber Übersetzungen zu ermöglichen...

Kann, muss aber nicht. I.a. hat man hier mehrere Orte, wo Übersetzungsinformationen angelegt werden (was ja nicht gerade ein Vorteil ist). Die Lookup-Tabellen haben nur dann Sinn, wenn die Ausprägung in einer View/Query verwendet wird (Stichwort: Report). Es ist dann nämlich überflüssig, im Report die Ausprägungen vorzuhalten (was nebenbei manchmal echt lästig ist, vor allen Dingen, wenn es sich um einen externen Reportgenerator handelt).

Lookuptabellen sind u.a. sinnvoll, wenn man die Dateneingabe per Auswahl (Combo, Radio, etc.) ermöglichen will. Früher gab es ja die beliebten 'Kennziffern' (die gar keine 'Ziffern', sondern Ziffernfolgen waren), die die Datentypisten in ausgedruckter Form rund um den Bildschirm geklebt haben. Da war dann der Staubsauger '0125' und der Montag die '1'.

Zitat:

Zitat von jobo (Beitrag 1242639)

Viele der führenden Anbieter eines RDBMS bieten Datumsarithmetik inkl. Wochentag nach ISO.

Richtig, Aber: Vorsicht! Falle! 'SET DATEFIRST'

Allgemein gesehen dreht sich die Diskussion bzw. das Unverständnis von nahpetS' Ansatz um die Frage, ob man seine DB als 2.xNF oder 3NF ablegen sollte sowie enventuell einiger nicht geklärter Fragen, wozu man Lookuptabellen verwendet (Ausprägung vs. Semantik).

In der DB habe ich natürlich irgendwann eine Abfrage auf '1' (wenn z.B. jeden Montag eine Wartung durchgeführt wird oder sonstwas gemacht wird). Irgendwann muss ich mich im DB-Umfeld auf die Bedeutung der einzelnen Werte festlegen. Es wäre fatal, hier in der Lookuptabelle nachzuschlagen, ob da 'Montag' drinsteht.

Zitat:

Zitat von Lemmy (Beitrag 1242637)

aber warum sollte man denn beim Programmieren dann so was umständliches wie Enums und Konstanten verwenden?

Es erzeugt besser lesbaren Code:

Delphi-Quellcode:

If Day=1 Then 
  StarteDieWartung;
// vs.
If Day=Monday Then
  StarteDieWartung;

[Klaus01]

Guten Morgen,

so schaut meine Tabelle jetzt aus.

Code:

CREATE TABLE "scheduledActionTable"
(
  "pkId" bigint NOT NULL,
  "deviceId" bigint NOT NULL,
  "time" time without time zone NOT NULL,
  action character(5)[],
  "daysOfWeek" bit(8)[],
  CONSTRAINT "scheduledActionTable_pkey" PRIMARY KEY ("pkId"),
  CONSTRAINT "scheduledActionTable_deviceId_fkey" FOREIGN KEY ("deviceId")
      REFERENCES "deviceTable" ("pkId") MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)

Die Wochentage sind in einem Byte codiert.
Die Wochentage hätten dann folgende Werte:

Code:

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

Ich denke das ist ein gangbarer Weg - oder übersehe ich da etwas entscheidendes?

Grüße
Klaus

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

[Jumpy]

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

(Ich frage weil ich bald sowas ähnliches machen soll, allerdings etwas komplexer. Im Prinzip sollen die Zeiten wie im Taskmanager von Windows konfigurierbar sein, d.h. ich brauche im Datenmodell Felder wie Startzeit, Endzeit, Wiederholung alle X Minuten usw. Soll aber nicht das Thema meiner Frage sein, da ich dazu bestimmt in Kürze einen eigenen Thread starten werden)

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?

[Sir Rufo]

Zitat:

Zitat von jobo (Beitrag 1242645)

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:

Zitat von Jumpy (Beitrag 1242646)

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:

Zitat von Klaus01 (Beitrag 1242650)

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:

Zitat von Sir Rufo (Beitrag 1242648)

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:

Zitat von Sir Rufo (Beitrag 1242648)

@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 Form

Delphi-Quellcode:

if Day = Monday then

einfacher zu lesen als

Delphi-Quellcode:

if Day = 1 then

. Aber wenn der Anwender nun Montag eingibt, muss ich dann das Programm ändern auf

Delphi-Quellcode:

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:

Zitat von p80286 (Beitrag 1242656)

Zitat:

Zitat von Sir Rufo (Beitrag 1242648)

@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:

Zitat von p80286 (Beitrag 1242656)

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:

Zitat von Sir Rufo (Beitrag 1242648)

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:

Zitat von p80286 (Beitrag 1242656)

Zitat:

Zitat von Sir Rufo (Beitrag 1242648)

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:

Zitat von Sir Rufo (Beitrag 1242648)

Zitat:

Zitat von Mikkey (Beitrag 1242714)

Zitat:

Zitat von Sir Rufo (Beitrag 1242648)

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:

Zitat von Sir Rufo (Beitrag 1242648)

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:

Zitat von Sir Rufo (Beitrag 1242725)

Somit kann dein Eintrag so gar nicht eingetragen werden.

Damit haste natürlich Recht.

Zitat:

Zitat von Sir Rufo (Beitrag 1242725)

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:

Zitat von Sir Rufo (Beitrag 1242705)

Zitat:

Zitat von p80286 (Beitrag 1242656)

Zitat:

Zitat von Sir Rufo (Beitrag 1242648)

@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:

Zitat von nahpets (Beitrag 1242728)

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:

Zitat von p80286 (Beitrag 1242733)

Zitat:

Zitat von nahpets (Beitrag 1242728)

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.