In welchem Format Datum abspeichern?
Frank.
- datenbank
1 miku0 MichiN0 Bademeister0 Tom
0 Vinzenz Mai0 Tom
Hallo zusammen,
ich bekomme aus ASCII-Dateien kilometerlang Daten, die ich in MySQL schreibe. Unter anderem auch zu jedem DS ein Datum in der Form MM/TT/JJJJ hh:mm:ss (z.B. 11/05/2008 16:54:23). Meine Frage: Forme ich das vor dem Insert in irgendetwas anderes um, macht das MySQL selbst (bin mit den Datum-Zeit-Funktionen nicht so richtig warm geworden), oder speichere ich das einfach als String ab und forme das hinterher mit php um? Letztes fällt eigentlich aus, da ich über das Datum Abfragen laufen lassen will (a la SELECT XY WHERE DATE < bla AND DATE > blubb)
Frank
Hi,
ich bekomme aus ASCII-Dateien kilometerlang Daten, die ich in MySQL schreibe. Unter anderem auch zu jedem DS ein Datum in der Form MM/TT/JJJJ hh:mm:ss (z.B. 11/05/2008 16:54:23) [..]
gibt es dafür nicht Datetime ?
grüße
Hi Frank,
das macht sicher jeder anders. _Ich_ habe mir angewöhnt, Datums/Zeit-Kombinationen _immer_ als Unixtime zu speichern, weil ich das bei Abfragen und Vergleichen als am unkompliziertesten empfinde.
Ich hab zB. eine Tabelle, wo es auch eine Spalte 'created' gibt. Wenn ich jetzt alle Datensätze, die älter als 1 Stunde sind, löschen möchte, erzeuge ich mir ein $old=time()-3600
und brauche dann im Query nur nach Datensätzen zu suchen, WHERE 'created' <= $old
ist, ohne noch weiter irgendwas umrechnen zu müssen. Aber das ist, wie gesagt, Geschmacksache.
Mit lieben Grüßen aus Wien
Michi
Hi MichiN,
_Ich_ habe mir angewöhnt, Datums/Zeit-Kombinationen _immer_ als Unixtime zu speichern, weil ich das bei Abfragen und Vergleichen als am unkompliziertesten empfinde.
Der Timestamp hat aber einen gegenueber Datetime wesentlich kleineren Wertebereich. Willst Du zum Beispiel geschichtliche Daten speichern, wirst Du das Format Datetime (bzw. wahrscheinlich nur Date) brauchen.
weil ich das bei Abfragen und Vergleichen als am unkompliziertesten empfinde.
Der Abfragekomfort ist zunaechst mal der gleiche, weil Du die beiden Typen mit denselben Formaten ansprechen kannst.
viele Gruesse
der Bademeister
Hi Bademeister,
Der Timestamp hat aber einen gegenueber Datetime wesentlich kleineren Wertebereich. Willst Du zum Beispiel geschichtliche Daten speichern, wirst Du das Format Datetime (bzw. wahrscheinlich nur Date) brauchen.
da hast Du natürlich völlig Recht. Ich sprach ja auch nur von meiner DB-Situation und davon, dass mir das subjektiv so am Liebsten ist.
Mit lieben Grüßen aus Wien
Michi
Hi,
Willst Du zum Beispiel geschichtliche Daten speichern, wirst Du das Format Datetime (bzw. wahrscheinlich nur Date) brauchen.
Da braucht man gar nicht historisch zu werden. Für das Geburtsdatum meines Bruders ist der UNIX-Timestamp schon unbrauchbar... ;)
LG
Da braucht man gar nicht historisch zu werden. Für das Geburtsdatum meines Bruders ist der UNIX-Timestamp schon unbrauchbar... ;)
Oooch, wie taktlos von Dir. Ab einem gewissen Punkt schweigt man ueber so etwas ;-)
viele Gruesse,
der Bademeister
Hi,
Der Timestamp hat aber einen gegenueber Datetime wesentlich kleineren Wertebereich. Willst Du zum Beispiel geschichtliche Daten speichern, wirst Du das Format Datetime (bzw. wahrscheinlich nur Date) brauchen.
genau aus diesem Grunde habe ich mir die time() Geschichten abgewöhnt.
Und Mysql hatten mal Probleme mit den hauseigenen Zeitstempeln, weiss aber auch nicht mehr was das genau war, aber eben seit dem nutze ich meisstens das Format:
YYYYmdHis = 17881121134012 = 21. November 1788 um 13:40 Uhr 12 Sekunden
Bisher klappt das auch ganz gut, für die Umrechnung habe ich eine Funktion geschrieben. Und Vergleichsrechnungen gehen sowohl in DB als auch auf in Scripten. Sortierungen sowieso.
Aber wahrscheinlich gibt es gute Gründe, warum ich mir das abgewöhnen sollte. Ich höre?
Peter
yo,
aber eben seit dem nutze ich meisstens das Format:
YYYYmdHis = 17881121134012 = 21. November 1788 um 13:40 Uhr 12 Sekunden
als welchen Datentyp speicherst du den dieses format ab in der Datenbank ?
Ilja
Hi,
als welchen Datentyp speicherst du den dieses format ab in der Datenbank ?
Varchar
Peter
yo,
»» als welchen Datentyp speicherst du den dieses format ab in der Datenbank ?
»»Varchar
hmm, und das bringt dich nicht selbst zum nachdenken ? damit schließt du alle wunderbaren datumsspezifischen funktinalitäten des jeweiligen dbms aus und musst sie mühsam selbst implementieren. mal davon abgesehen, dass die fehleranfälligkeit sehr hoch ist, warum etwas selbst machen, was mir das dbms schon von hause aus bietet ? und jedesmal wenn eine andre applikation darauf zugreifen will, dann musst auch diese wieder diese funktionaltät neu erfinden.....
Ilja
echo $begrüßung;
Und Mysql hatten mal Probleme mit den hauseigenen Zeitstempeln, weiss aber auch nicht mehr was das genau war, aber eben seit dem nutze ich meisstens das Format:
Vielleicht dies: Es gab beim Versionsschritt von 4.0 zu 4.1 eine Änderung im Ausgabeformat. Bis 4.0 war es 20090219093542 seit 4.1 ist es 2009-02-19 09:35:42, also mit Trennzeichen dazwischen und entspricht damit dem Ausgabeformat von DATETIME. Die Zusammenschreibweise hatte offensichtlich bei den Anwendern zu Verwechslungen mit dem Unix-Timestamp geführt, der ja Sekunden zählt. Jedenfalls sind nach meiner Beobachtung schon seit langem keine Fragen mehr aufgetaucht, die diese Verwechslung als Ursache haben.
Bisher klappt das auch ganz gut, für die Umrechnung habe ich eine Funktion geschrieben. Und Vergleichsrechnungen gehen sowohl in DB als auch auf in Scripten. Sortierungen sowieso.
Wenn du das MySQLs hauseigenes Datumsformat verwendest, brauchst du keine Umrechnungen. Lediglich eine Formatierung bei der Eingabe und eine Ausgabeformatierung. Das hat den Vorteil, dass man MySQLs umfangreiche Datums- und Zeitfunktionen verwenden kann.
Bei TIMESTAMP versus DATETIME kommt es darauf an, was man machen will. Will man ein beliebiges Datum (mit oder ohne Zeit) speichern, dann nimmt man DATE(TIME). TIMESTAMP ist zum Festhalten von aktuellen Zeitpunkten gedacht, also zum Beantworten der Frage, wann ein Datensatz angelegt oder zuletzt geändert wurde. Für diesen Zweck stellt MySQL eine Automatik bereit, die beim Anlegen und/oder Ändern ein TIMESTAMP-Feld aktualisieren kann.
echo "$verabschiedung $name";
Hi Peter,
[...] aber eben seit dem nutze ich meisstens das Format:
YYYYmdHis = 17881121134012 = 21. November 1788 um 13:40 Uhr 12 Sekunden
Willst Du damit zum Ausdruck bringen, dass Du diesen ganzen Rattenschwanz speicherst, um ein einziges Datum abzuspeichern? Oder was genau ist hier "das Format"?
viele Gruesse
der Bademeister
Hallo
»» YYYYmdHis = 17881121134012 = 21. November 1788 um 13:40 Uhr 12 Sekunden
Willst Du damit zum Ausdruck bringen, dass Du diesen ganzen Rattenschwanz speicherst, um ein einziges Datum abzuspeichern? Oder was genau ist hier "das Format"?
Das Format heißt TIMESTAMP und hat im obigen Fall den Wert 17881121134012. Das wurde in diesem Thread aber schon an mehreren Stellen angesprochen.
Tschö, Auge
Hi Auge,
Das Format heißt TIMESTAMP und hat im obigen Fall den Wert 17881121134012. Das wurde in diesem Thread aber schon an mehreren Stellen angesprochen.
"Das Format" von Peter ist wohl kaum TIMESTAMP, wenn er seine Daten als VARCHAR speichert.
viele Gruesse
der Bademeister
yo,
Hallo
»» »» YYYYmdHis = 17881121134012 = 21. November 1788 um 13:40 Uhr 12 Sekunden
»»
»» Willst Du damit zum Ausdruck bringen, dass Du diesen ganzen Rattenschwanz speicherst, um ein einziges Datum abzuspeichern? Oder was genau ist hier "das Format"?Das Format heißt TIMESTAMP und hat im obigen Fall den Wert 17881121134012. Das wurde in diesem Thread aber schon an mehreren Stellen angesprochen.
dein link könnte andeuten, dass es sich hier tatsächlich um den datentyp timestamp handelt. aber wenn ich mich nicht ganz irre (vielleicht habe ich ja was übersehen), sagte peter bereits, dass er es als VARCHAR gespeichert hat.
Ilja
Hallo
»» Das Format heißt TIMESTAMP und hat im obigen Fall den Wert 17881121134012. Das wurde in diesem Thread aber schon an mehreren Stellen angesprochen.
dein link könnte andeuten, dass es sich hier tatsächlich um den datentyp timestamp handelt.
Die Frage von Bademeister bezog sich, so wie ich sie las, auf das *Format*, das das des Datentyps TIMESTAMP ist. Der Link verweist natürlich auf den Datentyp, weil das Format dort erklärt wird (Wo hätte ich sonst hinlinken sollen?). Insofern kann das natürlich missverständlich sein.
aber wenn ich mich nicht ganz irre (vielleicht habe ich ja was übersehen), sagte peter bereits, dass er es als VARCHAR gespeichert hat.
Da hast du nix übersehen und ich habe es an der Stelle einfach ignoriert. Dass es albern ist, das richtige Format mit dem falschen Datentyp zu speichern (auch wenn *ich* DATETIME verwenden würde), da man sich der nützlichen Funktionen des richtigen Datentyps beraubt, ist klar. Aber das wurde ja nun auch schon vor meinem "TIMESTAMP-Posting" angemerkt.
Tschö, Auge
Hello,
Die Frage von Bademeister bezog sich, so wie ich sie las, auf das *Format*, das das des Datentyps TIMESTAMP ist.
Irgendwie geht mir das schon länger durch den Kopf. Das Speicherfomat ist doch eigentlich immer "binär". Was sich unterscheidet, sind die zugehörige Transformationsvorschriften für
Speicherformat zu Verarbeitungsformat
Speicherformat zu Darstellungsformat zu zugehörigem Bildzeichen
...
Und wenn man jetzt noch spitzfindiger werden will, dann ist das Speicherformat sogar noch anders:
Analog, MFM, RLL, PWM und so weiter...
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
hi Peter,
Aber wahrscheinlich gibt es gute Gründe, warum ich mir das abgewöhnen sollte. Ich höre?
Ne, es gibt immer Gründe, Datumsangaben 'eigenwillig' zu speichern. Ich hab z.B. Kalenderscripts, die ohnehin mit dem Julianischen Tag (Tage sind von 1.1.-4713 an bis heute fortlaufend durchnumeriert) rechnen, da speichere ich das Datum ganz einfach als fortlaufenden Tag.
Beispiel (Speicherung der Mondphasen für die Jahre 1700 bis 2199)
Fortlaufend durchnumerierte Tage sind insbesondere für die Berechnung der Kalenderwoche nach DIN 1355, des Wochentags und die Ausgabe tabellarischer Monate in HTML oder Text unerlässlich, da bringen mir die Datumsfunktionen und ~FeldTypen eines DBMS keinerlei Vorteile, ganz abgesehen vom bescheidenen Umfang der Epoche in denen solche Funktionen richtig rechnen würden.
Hotte
Hello,
das macht sicher jeder anders. _Ich_ habe mir angewöhnt, Datums/Zeit-Kombinationen _immer_ als Unixtime zu speichern, weil ich das bei Abfragen und Vergleichen als am unkompliziertesten empfinde.
Das macht ganz gewiss nicht jeder (vorausdenkende Programmierer) anders, denn die Variationsbreite ist nicht sehr groß.
Es hängt im wesentlichen davon ab, ob im Darstellungsformat der Daten gespeichert wird (Direkte Umsetzung von Code zu Bildzeichen) oder in einem typgerechten Format gespeichert wird. Typgerecht bedeutet dann, dass man die Daten in einerm Speicherplatzsparenden Format speichert.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
Hallo,
ich bekomme aus ASCII-Dateien kilometerlang Daten, die ich in MySQL schreibe. Unter anderem auch zu jedem DS ein Datum in der Form MM/TT/JJJJ hh:mm:ss (z.B. 11/05/2008 16:54:23). Meine Frage: Forme ich das vor dem Insert in irgendetwas anderes um,
das ist sinnvoll. Und zwar am allerbesten in einen der Datums-/Zeitdatentypen, den Dein Datenbankmanagementsystem unterstützt.
macht das MySQL selbst
Nein.
(bin mit den Datum-Zeit-Funktionen nicht so richtig warm geworden),
Du kannst mit diversen Konvertierungsfunktionen eine Umformung vornehmen lassen. So böte sich im Fall von UNIX-Timestamps die Konvertierung per FROM_UNIXTIME an.
oder speichere ich das einfach als String ab und forme das hinterher mit php um?
Nein, sowas ist grausam. Noch schlimmer als das Speichern von UNIX-Timestamps, was schon schlimm genug ist.
Letztes fällt eigentlich aus, da ich über das Datum Abfragen laufen lassen will (a la SELECT XY WHERE DATE < bla AND DATE > blubb)
BETWEEN ... AND ist ein eleganter Operator :-)
Nochmals: Die mit riesigem Abstand sinnvollste Methode, Datumsangaben in einer Datenbank abzuspeichern ist die Verwendung des dafür vorgesehenen Datentyps - bei MySQL kämen somit DATETIME und DATE in Frage (wenn man den Zauber von TIMESTAMP nicht benötigt). Danach kommt eine halbe Ewigkeit lang nichts.
Freundliche Grüße
Vinzenz
Hello,
Daten sollten immer in einem leicht verarbeitbaren und vor allem verlustfreien Format abgespeichert werden. Es ist daher sinnvoll, auf die Sortierfähigkeit der Daten im Darstellungsformat zu achten.
Dabei müssen dann z.B., wenn man im ASCII-Format abscpeichert
Texte linksbündig, ggf. aufgefüllt mit Leerzeichen oder NULL
Daten Jahr, Monat, Tag, Stunde, Minute, Sekunde
Zahlen rechtsbündig, ggf. mit führenden Nullen
gespeichert werden.
Dass DBMS davon wieder abweichen können, hängt davon ab, dass sie sich bereits wieder merken, welchen Datentyp welche Spalte hat und daher eigene Methoden/Funktionen für jeden Typ verwenden können.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg