MYSQL STRING Datum zu TIMESTAMP konvertieren

[Peter]

Hallo

Das ist jetzt eine prinzipielle Interessensfrage.

Ich habe da eine Table mt ca 2 MIO Einträgen.. Darin gibt es eine Spalte die sich Datum nennt.. intelligenter weiße hat da jemand eine VARCHAR feld dafür genommen und ein String im Format  'DD.MM.YYYY HH:MM:SS' mit PHP reingeschrieben. Ich muß nun die Tabelle zu einer anderen Tabelle hinzufügen, die aber eine DATUMS feld vom type timestamp hat. Hat jemand eine Idee wie ich MYSQL hier intern eine typenumwandlung für das DATUM STRING Feld zu TIMESTAMP machen kann.

Ja ich weiß, ich kann es locker per PHP machen, mich würde aber interessieren wie und ob so etwas mit MYSQL direkt ginge.

lg

[dedlfix]

Hi!

Hat jemand eine Idee wie ich MYSQL hier intern eine typenumwandlung für das DATUM STRING Feld zu TIMESTAMP machen kann.
Ja ich weiß, ich kann es locker per PHP machen, mich würde aber interessieren wie und ob so etwas mit MYSQL direkt ginge.

Auch MySQL hat Date and Time Functions, unter anderem STR_TO_DATE().

Lo!

[Peter]

Hi!

Hat jemand eine Idee wie ich MYSQL hier intern eine typenumwandlung für das DATUM STRING Feld zu TIMESTAMP machen kann.
Ja ich weiß, ich kann es locker per PHP machen, mich würde aber interessieren wie und ob so etwas mit MYSQL direkt ginge.

Auch MySQL hat Date and Time Functions, unter anderem STR_TO_DATE().

Ah danke, hab die Funktion dazu nicht gefunden gehabt, da gibts ja wirklich eine riesen Menge dazu.

so funktionierts dann
UNIX_TIMESTAMP(STR_TO_DATE(datum_field,'%d.%m.%Y %H:%i:%S'))

thx lg

[Sven Rautenberg]

Moin!

so funktionierts dann
UNIX_TIMESTAMP(STR_TO_DATE(datum_field,'%d.%m.%Y %H:%i:%S'))

Eien Unix-Timestamp ist nicht das, was man in ein TIMESTAMP-Feld füllen will.

Unix-Timestamps passen aber sehr gut in unsigned INT (noch bis 2038) oder BIGINT rein.

- Sven Rautenberg

[globe]

n'abend,

Eien Unix-Timestamp ist nicht das, was man in ein TIMESTAMP-Feld füllen will.

Der Unix-Timestamp (auch epoch genannt, Anzahl Sekunden seit 01.01.1970 00:00:00) ist eigentlich nichts was man in einer Datenbank speichern will. Der Timestamp (YYYY-MM-DD HH:MM:SS) braucht nicht mehr Speicherplatz, ist aber direkt mit den MySQL'schen Datumsfunktionen benutzbar. Und im Zweifelsfall via PhpMyAdmin (o.ä.) für Menschen lesbar. Datümser™ will man nicht als Integer speichern.

Unix-Timestamps passen aber sehr gut in unsigned INT (noch bis 2038) oder BIGINT rein.

Für Datums-Typen (Date, Datetime, Timestamp, ..) kann das DBMS automatisch Datumstransformationen durchführen. Für Integer eher nicht so.

CREATE TABLE IF NOT EXISTS `dateconv` (  
  `datum_field` varchar(50) NOT NULL COMMENT 'Datum als String "DD.MM.YYYY HH:MM:SS"',  
  `timestamp_field` timestamp NULL default NULL COMMENT 'Datum als Timestamp'  
) ENGINE=InnoDB DEFAULT CHARSET=utf8;  
  
INSERT INTO `dateconv` (`datum_field`, `timestamp_field`) VALUES  
('13.10.2010 12:12:12', NULL),  
('15.08.2010 02:03:04', NULL);  
  
UPDATE dateconv SET timestamp_field = STR_TO_DATE(datum_field,'%d.%m.%Y %H:%i:%S');

weiterhin schönen abend...

[dedlfix]

Hi!

Eien Unix-Timestamp ist nicht das, was man in ein TIMESTAMP-Feld füllen will.
Der Unix-Timestamp (auch epoch genannt, Anzahl Sekunden seit 01.01.1970 00:00:00) ist eigentlich nichts was man in einer Datenbank speichern will.

Sagen wir mal so: Intern speichert MySQL anzunehmenderweise zwar einen Unix-Timestamp in einem TIMESTAMP-Feld, doch nach außen hin sieht er wie ein DATETIME aus und muss auch genauso behandelt werden.

Der Timestamp (YYYY-MM-DD HH:MM:SS) braucht nicht mehr Speicherplatz, ist aber direkt mit den MySQL'schen Datumsfunktionen benutzbar. Und im Zweifelsfall via PhpMyAdmin (o.ä.) für Menschen lesbar. Datümser™ will man nicht als Integer speichern.

Der gleiche Speicherverbrauch ((4-Byte-)Integer und TIMESTAMP) unterstützt meine obige Annahme, die angenehmere Verarbeitung aufgrund der "Außenwirkung" will man ebenfalls nicht missen. Wie die Datümser™ intern gespeichert werden, kann ja egal sein, wie sie behandelt werden, ist es nicht. Um eine Formatierung zu bekommen, die für einen bestimmten Anwendungsfall erforderlich ist, kann man entspechende Funktionen verwenden (zum Beispiel DATE_FORMAT() und auch UNIX_TIMESTAMP()).

Lo!

[globe]

n'abend,

Der gleiche Speicherverbrauch ((4-Byte-)Integer und TIMESTAMP) unterstützt meine obige Annahme, die angenehmere Verarbeitung aufgrund der "Außenwirkung" will man ebenfalls nicht missen. Wie die Datümser™ intern gespeichert werden, kann ja egal sein, wie sie behandelt werden, ist es nicht. Um eine Formatierung zu bekommen, die für einen bestimmten Anwendungsfall erforderlich ist, kann man entspechende Funktionen verwenden (zum Beispiel DATE_FORMAT() und auch UNIX_TIMESTAMP()).

Argumentierst du jetzt pro TIMESTAMP oder pro INTEGER? Zwischen den Zeilen interpretere ich ersteres...

Auf den Punkt gebracht:

Wenn du TIMESTAMP statt INTEGER zum speichern deiner Datümser™ benutzt hast du den selben Speicherverbrauch, aber direkten Zugriff auf die Datumsfunktionen. Würdest du INTEGER speichern müsstest du zunächst FROM_UNIXTIME() anwenden um dann etwa YEAR() oder DATE_SUB() nutzen zu können.

weiterhin schönen abend...

[dedlfix]

Hi!

Der gleiche Speicherverbrauch ((4-Byte-)Integer und TIMESTAMP) unterstützt meine obige Annahme, die angenehmere Verarbeitung aufgrund der "Außenwirkung" will man ebenfalls nicht missen. Wie die Datümser™ intern gespeichert werden, kann ja egal sein, wie sie behandelt werden, ist es nicht. Um eine Formatierung zu bekommen, die für einen bestimmten Anwendungsfall erforderlich ist, kann man entspechende Funktionen verwenden (zum Beispiel DATE_FORMAT() und auch UNIX_TIMESTAMP()).

Argumentierst du jetzt pro TIMESTAMP oder pro INTEGER? Zwischen den Zeilen interpretere ich ersteres...

Ich argumentiere pro TIMESTAMP mit dem vielleicht unnützen Hintergrundwissen, dass der intern auch nur ein Integer ist. Allerdings kann man aus diesem Wissen ableiten, warum der TIMESTAMP den selben Wertebereichsbedingungen unterliegt wie ein auf Integer basierender Unix-Timestamp. (von 1970 bis ~2038, und wenn man die negativen Werte noch dazunimmt, von ~1901)

Auf den Punkt gebracht:
Wenn du TIMESTAMP statt INTEGER zum speichern deiner Datümser™ benutzt hast du den selben Speicherverbrauch, aber direkten Zugriff auf die Datumsfunktionen. Würdest du INTEGER speichern müsstest du zunächst FROM_UNIXTIME() anwenden um dann etwa YEAR() oder DATE_SUB() nutzen zu können.

Genau. Wobei mir grad noch einfällt, dass TIMESTAMP unter MySQL eigentlich nicht für das Speichern beliebiger Datümser™ vorgesehen ist, sondern eher reinweg als Zeitstempel im eigentlichen Sinne. Denn TIMESTAMP-Spalten haben noch eine eigene Art von Magie eingebaut, die eventuell hinderlich für normale Anwendungen ist. Der bevorzugte Typ für beliebige Datumsangeben sollte DATE(TIME) sein.

Lo!