Datum / Uhrzeit speichern

[Bernd]

Hallo,

eine Frage, wie speichere ich das Datum und Uhrzeit in der Datenbank? Ich möchte damit Erinnerungen per Cron verschicken, meine Idee

Oder das Datum lieber in ein Feld mit Datetime?

[dedlfix]

Tach!

eine Frage, wie speichere ich das Datum und Uhrzeit in der Datenbank? Ich möchte damit Erinnerungen per Cron verschicken, meine Idee

Oder das Datum lieber in ein Feld mit Datetime?

Genau so, wenn du keinen Grund findest, dass Datum und Zeit zwei getrennte eigenständige Einheiten sind.

dedlfix.

[TS]

Hello,

eine Frage, wie speichere ich das Datum und Uhrzeit in der Datenbank? Ich möchte damit Erinnerungen per Cron verschicken, meine Idee

Oder das Datum lieber in ein Feld mit Datetime?

Genau so, wenn du keinen Grund findest, dass Datum und Zeit zwei getrennte eigenständige Einheiten sind.

Das wäre z. B. dann der Fall, wenn man unabhängig vom Datum auch schnelle Direktzugriffe auf zeitliche Einträge benötigt. Das ist für Statistiken oft der Fall, wenn man z. B. schnell aggregieren will, was/wieviel zwischen 13:00 und 14:00 Uhr los war...

Glück Auf
Tom vom Berg

[Christian Kruse]

Hallo TS,

Das wäre z. B. dann der Fall, wenn man unabhängig vom Datum auch schnelle Direktzugriffe auf zeitliche Einträge benötigt. Das ist für Statistiken oft der Fall, wenn man z. B. schnell aggregieren will, was/wieviel zwischen 13:00 und 14:00 Uhr los war...

Auch dann ist es idR sinnvoller ein Datum-Zeit-Feld zu haben und mit den Datumsfunktionen zu arbeiten. Ggfls nochmal einen Index über den benötigten Ausdruck drüber legen (bzw bei MySQL mit dem Trigger-Workaround arbeiten).

LG,
CK

[TS]

Hello,

Hallo TS,

Das wäre z. B. dann der Fall, wenn man unabhängig vom Datum auch schnelle Direktzugriffe auf zeitliche Einträge benötigt. Das ist für Statistiken oft der Fall, wenn man z. B. schnell aggregieren will, was/wieviel zwischen 13:00 und 14:00 Uhr los war...

Auch dann ist es idR sinnvoller ein Datum-Zeit-Feld zu haben und mit den Datumsfunktionen zu arbeiten. Ggfls nochmal einen Index über den benötigten Ausdruck drüber legen (bzw bei MySQL mit dem Trigger-Workaround arbeiten).

Nur damit ich Dich richtig verstehe: Du meinst sicher, dass es dann sinnvoll ist, einen eigenen Index über die Zeit zu legen?

Das ist mWn bei MySQL nur möglich, wenn man die Zeit in einer eigenen Spalte hält. Oder kann MySQL jetzt auch Indexe über Teilstrings/-spalten bzw. Funktionsergebnisse?

Glück Auf
Tom vom Berg

[Christian Kruse]

Hallo TS,

Nur damit ich Dich richtig verstehe: Du meinst sicher, dass es dann sinnvoll ist, einen eigenen Index über die Zeit zu legen?

Nein. Über einen Ausdruck.

Das ist mWn bei MySQL nur möglich, wenn man die Zeit in einer eigenen Spalte hält. Oder kann MySQL jetzt auch Indexe über Teilstrings/-spalten bzw. Funktionsergebnisse?

Der übliche Workaround für Indexe über Ausdrücke in MySQL ist eine vorberechnete Spalte, die das Ergebnis des Ausdrucks enthält und über einen Trigger aktualisiert wird.

LG,
CK

[TS]

Hello,

Nur damit ich Dich richtig verstehe: Du meinst sicher, dass es dann sinnvoll ist, einen eigenen Index über die Zeit zu legen?

Nein. Über einen Ausdruck.

Das ist mWn bei MySQL nur möglich, wenn man die Zeit in einer eigenen Spalte hält. Oder kann MySQL jetzt auch Indexe über Teilstrings/-spalten bzw. Funktionsergebnisse?

Der übliche Workaround für Indexe über Ausdrücke in MySQL ist eine vorberechnete Spalte, die das Ergebnis des Ausdrucks enthält und über einen Trigger aktualisiert wird.

Bevor ich dann einen Index über Datetime und einen über den per Trigger berechneten Ausdruck für Time lege, halte ich die Werte für Date und Time lieber getrennt und lasse jeweils einen Index über die Spalten laufen. Das spart den Trigger und macht den Platzbedarf für die Indexe kleiner.

len(Index(Datetime)) > len(Index(Date))

Anderenfalls könnte man noch einen zusätzlichen Index über Date+Time legen. Das kostet dann zwar auch Speicherzeit und Handlungszeit beim DMS, spart aber den Trigger.

Was macht der Optimizer, wenn man dann trotzdem über den Ausdruck Date+Time sucht, wenn über beide Spaöten ein eigener Index besteht? Ich kann das jetzt gerade leider nicht ausprobieren. Wäre nett, wenn das mal jemand anderes beantworten könnte ;-)

Jedenfalls ist es mMn falsch, bei Der DatenModellDefinition die vorgesehenen Anwendungsszenarien außer Betracht zu lassen. Dedlfix hatte deshalb wohl auch schon die möglichen Sonderbedingungen berücksichtigt.

Glück Auf
Tom vom Berg

[pl]

len(Index(Datetime)) > len(Index(Date))

Ist das so? Ich dachte immer die Länge eines Index spielt nur bei Strings eine Rolle.

MfG

[TS]

Hello,

len(Index(Datetime)) > len(Index(Date))

Ist das so? Ich dachte immer die Länge eines Index spielt nur bei Strings eine Rolle.

Das war als Beispiel zu sehen.
Aber selbstverständlich benötigf Datetime mehr Filespace als Date oder Time. Für die Indexe gilt dann entsprechendes.

Siehe auch Doku, hier für MariaDB. Für MySQL gibts auch sowas, ist mir aber mit dem Tablet zu müßig zu suchen.

Ich könnte mir auch vorstellen, dass das auch noch von der DBE abhängt. Bei MyISAM steigt man durch den Hexdump noch so einigermaßen durch. Bei InnoDB wirds dann schon eklig.

Aber generell waren Date, Datetime und Time irgend ein wildes BCD-Format mit Halbbytes und so, Während Timestamp tatsächlich als Int/Longint/Bigint oder wie auch immer der Typ heißen mag, gespeichert wird.

Glück Auf
Tom vom Berg

[pl]

Nun, 8 gegenüber 4 Bytes heißt ja nur, daß die Zahl numerisch größer ist. Und wenn YEAR auf 1 Byte abgebildet wird, kann das wohl kaum ein String sein, selbst wenn wir 1900 abziehen würden für einen String immernoch 3 Bytes verbleiben. Also ich denke, daß Date & Time quasi numerische Datentypen sind. Ansonsten könnte man mit Datum + Zeit nicht rechnen.

MFG

[TS]

Hello,

Nun, 8 gegenüber 4 Bytes heißt ja nur, daß die Zahl numerisch größer ist. Und wenn YEAR auf 1 Byte abgebildet wird, kann das wohl kaum ein String sein, selbst wenn wir 1900 abziehen würden für einen String immernoch 3 Bytes verbleiben. Also ich denke, daß Date & Time quasi numerische Datentypen sind. Ansonsten könnte man mit Datum + Zeit nicht rechnen.

Ja klar. Besonders die Aggregatsfunktionen sind da ja wichtig ;-P
Summe aller Datumse between ... ☆☆☆höhöhö☆☆☆

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

Zeit ist Geld, sagte der Ober und addierte das Datum zur Rechnung

Rolf

[pl]

Zeit ist Geld, sagte der Ober und addierte das Datum zur Rechnung

Leider ist das Jahr ein unsigned char MFG

[Rolf B]

Hallo pl,

Leider nicht. Oder wo steht das?

DATE belegt 3 Bytes, sagt die MariaDB Doku. Und sie sagt auch, dass ein Date vom 0001-01-01 bis 9999-12-31 gehen kann.

10000 Jahre, man braucht 14 Bit
12 Monate, man braucht 4 Bit
31 Tage, man braucht 5 Bit

Macht 23, eins ist übrig. Das Format reicht also auch noch für ein Marsjahr (knapp 2 Erdenjahre, man nehme 11 Monate mit 28 und 13 Monate mit 29 Tagen. Ab und zu lässt man mal einen Tag weg, um auf 686,980 Tage zu kommen).

Rolf

[dedlfix]

Tach!

Leider ist das Jahr ein unsigned char

Leider nicht. Oder wo steht das?

In China, da wird das aktuelle Jahr repräsentiert von: 🐷

dedlfix.

[pl]

Leider nicht. Oder wo steht das?

In der Doku zu MariaDB (hatte TS verlinkt) steht, daß fürs Jahr genau ein Byte reserviert ist. Also ein unsigned char und unsigned deswegen weil negative Jahre keinen Sinn machen.

Der Trick mit dem einen Byte funktioniert auch nur, weil 1900 addiert wird. So reicht für das Jahr eine dreistellige Zahl von 0 bis 255 was die Jahre 1900 bis 2125 ergibt.

MFG

PS: Perl rechnet auch mit 1900

$year contains the number of years since 1900. To get a 4-digit
            year write:

                $year += 1900;

aus der perldoc

[Rolf B]

Hallo pl,

ups, stimmt. Das habe ich nicht angeschaut. DATE ist anders, da ist mehr erlaubt.

Rolf

[pl]

ups, stimmt. Das habe ich nicht angeschaut. DATE ist anders, da ist mehr erlaubt.

Was aber auch nur zeigt, daß Date/Time numerische Datentypen sind. MFG

PS: Der Witz mit dem Datum zur Rechnung addieren ist uralt. Und neulich hatte ich eine Speisekarte der Mitropa aufm Desktop da dachte ich erst, das sei eine Rechnung. Es war jedoch die komplette Speisekarte, alles zusammengerechnet ergibt heutige Beträge für eine Mahlzeit: Und zwar ohne Datum. TWTD

[TS]

Hello,

ups, stimmt. Das habe ich nicht angeschaut. DATE ist anders, da ist mehr erlaubt.

Was aber auch nur zeigt, daß Date/Time numerische Datentypen sind. MFG

Nein, sie sind zusammengesetzte Datentypen. Man muss sie also erst wieder extrahieren und separieren, bevor man mit ihren Teilen nach bestimmten Regeln rechnen darf.

Und die Wertebereiche der verschiedenen Typen sind durchaus unterschiedlich. Wenn ich mich nicht verguckt habe, hat Datetime den größten Wertebereich. Man kann also Datetime nicht verlustfrei in Date+Time umwandeln.

Glück Auf
Tom vom Berg

[pl]

Natürlich sind die Wertebereiche unterschiedlich. Das ist ja der Sinn der Typisierung: Den Wertebereich, sprich die ByteLength feszulegen. MFG

[TS]

Hello,

Natürlich sind die Wertebereiche unterschiedlich. Das ist ja der Sinn der Typisierung: Den Wertebereich, sprich die ByteLength feszulegen.

Und trotzdem sind Datetime, Date keine numerischen Datentypen, sondern nur ihre Teiltypen sind dies. Man kann also nicht direkt damit Rechnen.

Time habe ich noch nicht genauer angeschaut.

Glück Auf
Tom vom Berg

[pl]

Hello,

Natürlich sind die Wertebereiche unterschiedlich. Das ist ja der Sinn der Typisierung: Den Wertebereich, sprich die ByteLength feszulegen.

Und trotzdem sind Datetime, Date keine numerischen Datentypen, sondern nur ihre Teiltypen sind dies. Man kann also nicht direkt damit Rechnen.

Es sind Objekte in denen numerische Datentype gekapselt sind. Und es gibt Methoden die das Rechnen implementieren. Für den Anwender ist diese API transparent: Er nimmt ein Datum und rechnet damit (Tage addieren usw.).

MFG

[Bernd]

Ok, hab beide Felder zu datetime zusammengelegt.