Korrekte Zeitraumabfrage bei Uhrumstellung

[nazar]

Guten Morgen,

ich soll für Industriemaschinen verschiedene Kennzahlen ermitteln.
Dabei sollen minutengenaue Zeitraumabfragen möglich sein. D.h ich schreibe die aktuellen Daten jede Minute und bei bestimmten Events weg.
Mein Problem ist nun, dass ich zwar immer schön die aktuelle DATETIME speichern kann, aber wenn die Uhr umgestellt wird, passen die alten Werte wieder nicht zu den neuen.

Die Tables für die Ermittlung der Qualität:

CREATE TABLE gutmenge(
 gmid INT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), 
 anzahl INT, 
 zeitpunkt DATETIME
 CONSTRAINT gm_pk PRIMARY KEY (gmid)
);
			
CREATE TABLE produktionsmenge(
 pmid INT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1),
 anzahl INT, 
 zeitpunkt DATETIME
 CONSTRAINT pm_pk PRIMARY KEY (pmid)
);

Für höhere Sicherheit wollte ich über die ID und den Zeitpunkt abfragen, um schonmal ein paar Fehler auszuschließen. Dabei fiel mir aber trotzdem keine Möglichkeit ein, eine korrekte Abfrage zu gewährleisten, da der Benutzer schließlich nur zwei Zeitpunkte eingibt.
Dann dachte ich mir, die Zeit wird nicht oft umgestellt und ich speichere die aktuelle Zeitversion mit. Allerdings ist die Steuereinheit anscheinend fehlerhaft und die Applikation stellt deswegen jeden Tag die Systemzeit um umgefähr eine Minute zurück.

Hat jemand eine Idee?

 

[nazar]

Sehe ich den Editbutton für Beiträge nicht oder wurde der entfernt? >_<
Die Statements hab ich aus dem Kopf gebaut und sehe gerade, dass sie so garnicht funktionieren.
Aber das Grundproblem gilt ja immernoch.
Gruß
Nazar

 

[SlaterB]

editieren kann man nur eine gewisse Zeit, manche Spassvögel nehmen viele Antworten gerne auf und löschen am Ende ihr erstes Posting,
so dass Threads ohne Sinn dastehen..

wie sieht denn deine DB konkret aus?
hast du Einträge a la

Id 15, Zeit 9:45, 30 sec
Id 16, Zeit 9:46, 15 sec
Id 17, Zeit 9:48, 59 sec
Id 18, Zeit 9:46, 08 sec // Zeitsprung, Annahme dass es in alter Zeit NACH 9:47, VOR 9:50 wäre
Id 19, Zeit 9:47, 20 sec // Annahme dass es in alter Zeit NACH 9:50 wäre
Id 20, Zeit 9:50, 59 sec
?

das zu händeln scheint doch erstmal eine logische Konzept-Frage,
mit SQL/ DB-Bereich muss man sich vorher nicht unbedingt beschäftigen

was soll passieren? welche Informationen bekommst du als Abfrage
"gib alles zwischen 9:47, 0 sec und 9:50, 0 sec"?

was soll dann dort hinein ganz konkret, welche Einträge?
wie sieht es mit der direkten Abfrage der Zeit aus, die dann zu Id 17 + 19 führt, ist das ok?

oder willst du Id 19 nicht mit drinhaben weil es nach alter Zeit nach 9:50 läge?
oder willst du Id 18 mit drinhaben da es nach alter Zeit gepasst hätte?

ohne die alte Zeit in irgendeiner Form abzuspeichern kann man das allein aus den DB-Daten nicht wirklich berechnen,
außer dir reicht es, aus dem Abstand von Id 17 und Id 18 einen Sprung von mindestens 2 Min 49 festzustellen,
natürlich könnten es auch 10 Stunden sein,
geht es dir darum?

oder möchtest du im Java-Programm (falls eins vorliegt) den Zeitwechsel bemerken und genauest möglich notieren?
dass ich Problem besteht ist sicherlich offensichtlich, aber schwer so allgemein zu besprechen,
was sind deine Ziele?
über deren Umsetzung könnte man diskutieren, aber kaum die Konzepte an sich (außer Vorschläge, die du vielleicht suchst, hm...)

 

[nazar]

Im Grunde dachte ich mir den Zeitwechsel irgendwie an die Datenbank mitzugeben.

Einträge sehen so aus:

id:8, anzahl:5532, zeitstempel: 2012-03-07 12:03:12.322

Eine Abfrage zur Qualität sieht z.B. so aus:
Der Benutzer will die Qualität aller Produkte von Mai bis Juli 2011 wissen.
Die Datenbank schaut nun auf die Tabelle "produktionsmenge" und subtrahiert den ersten Maiwert vom letzten Juniwert.
Danach das Selbe in der Tabelle "gutmenge".
Da kommt dann z.B. Produktionsmenge 100, Gutmenge 80.
80 / 100 = 80% der Produktion war in Ordnung.

Die Abfragen dabei in SQL und die Berechnung und Anzeige mit Graphen und Ähnlichem in Java.

Die ID sollte dabei überprüfen, ob ein in die Berechung einfließender Wert, logisch überhaupt schon vorhanden sein konnte, da mir die Systemzeit eben zu unsicher war.

Allerdings denke ich nicht, dass das dann wirklich funktioniert, da ein Zeitraum mit Systemzeitänderung mehrmals vorkommen kann und ich keine sichere Möglichkeit sehe, auszuwählen, welcher der Richtige ist.

Die Kennzahlen sollten für die Maschinen wirklich aussagekräftig sein. Deswegen wollte ich den Fehlerfall abfangen.
Ohne die Uhr über DCF einzustellen, sehe ich aber kaum eine Möglichkeit dazu.

Mit dem "übers Konzept reden" hast du Recht. Ich wollte es nur schon möglichst stehen haben, bevor ich mich daran mache das Ganze zu implementieren. Nicht dass ich die Datenbank hinterher wieder über den Haufen werfen muss.
Wie meine Kollegen aber schon meinten, verzettle ich mich gerade im Detail.

Gruß
Nazar