![]() |
AW: Datenbankdesign: wiederkehrende Ereignisse
Zitat:
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:
|
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. |
AW: Datenbankdesign: wiederkehrende Ereignisse
Zitat:
![]() Zitat:
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. |
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... |
AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
Zitat:
|
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. |
AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
Was nahpetS da gemacht hat, nennt sich
![]() Zitat:
Zitat:
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:
![]() 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:
Delphi-Quellcode:
If Day=1 Then
StarteDieWartung; // vs. If Day=Monday Then StarteDieWartung; |
AW: Datenbankdesign: wiederkehrende [Ereignisse] Aktionen
Guten Morgen,
so schaut meine Tabelle jetzt aus.
Code:
Die Wochentage sind in einem Byte codiert.
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 hätten dann folgende Werte:
Code:
Ich denke das ist ein gangbarer Weg - oder übersehe ich da etwas entscheidendes?Montag : 1 [1000 0000] Dienstag: 2 Mittwoch: 4 Donnerstag: 8 Freitag: 16 Samstag: 32 Sonntag: 64 [0000 0010] Grüße Klaus |
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. |
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 22:42 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz