Delphi-PRAXiS
Seite 2 von 4     12 34      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Datenbankdesign: wiederkehrende [Ereignisse] Aktionen (https://www.delphipraxis.net/178423-datenbankdesign-wiederkehrende-%5Bereignisse%5D-aktionen.html)

Sir Rufo 7. Jan 2014 22:35

AW: Datenbankdesign: wiederkehrende Ereignisse
 
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 8. Jan 2014 00:55

AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
 
@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 8. Jan 2014 07:11

AW: Datenbankdesign: wiederkehrende Ereignisse
 
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 8. Jan 2014 07:16

AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
 
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 8. Jan 2014 07:48

AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
 
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 8. Jan 2014 08:00

AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
 
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 8. Jan 2014 08:04

AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
 
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 8. Jan 2014 09:22

AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
 
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 8. Jan 2014 09:43

AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
 
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 8. Jan 2014 09:53

AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
 
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?


Alle Zeitangaben in WEZ +1. Es ist jetzt 00:12 Uhr.
Seite 2 von 4     12 34      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz