timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755(mysql4)

Habe unter mysql5 eine Tabelle mit der gleichen Syntax angelegt wie
unter mysql4:

CREATE TABLE d (
id int(7) NOT NULL auto_increment,
datEin timestamp(14) NOT NULL,
[...]

Das (14) ist deprecated unter mysql5, okay, kommt weg. Mein Problem ist
aber, daß in mysql5 der Timestamp anderst in der Datenbank abgelegt
wird, nämlich:

2007-01-11 15:47:55 statt 20070111154755

Ein Intranet-Anwendung mit php liest ebenfalls 2007-01-11 15:47:55
anstelle von 20070111154755 aus, was es notwendig machen würde, den
ganzen PHP-Code neu zu schreiben, der parst das Datum nämlich. Ich will
nun der Einfachheit mysql5 erklären, daß das Datumsformat in der Tabelle
20070111154755 sein soll wie in mysql4. Geht das? - Wenn ja, wie?

Gruss
Ekkard

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Ekkard Gerlach schrieb:

> [...] Mein Problem ist aber, daß in mysql5 der Timestamp anderst in
> der Datenbank abgelegt wird, nämlich:
>
> 2007-01-11 15:47:55 statt 20070111154755
>
> [...] Ich will nun der Einfachheit mysql5 erklären, daß das
> Datumsformat in der Tabelle 20070111154755 sein soll wie in mysql4.
> Geht das?

Laut geht
das nicht.

Aber der erste User Comment zeigt einen Trick auf, wie man die Queries
umbauen kann, so dass man wenigstens beim Lesen die Daten im alten
Format bekommt: einfach 0 hinzuaddieren (selber nicht probiert). Aus

SELECT datEin ...

wird also

SELECT datEin+0 ...

Vielleicht reicht Dir das ja schon.

Gruß. Claus
--
,~°O O
O ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Claus Reibenstein schrieb:

> SELECT datEin+0 ...
BEsten Dank! Dieses Bsp geht bei mir genauso wie in dem comment.
Aber: im PHP-Programmcode eingebaut erweist sich dann das datEin nicht
einmal mehr mit druckbar: echo $res[datEin] ist leer!! Ebenso dann die
substr(....[datEin],X,Y)! Leider ist offenbar sehr viel mehr Änderung
des Programmcodes notwendig, auch alleine schon zum Auslesen.

Daher: Schluss! Suse 9.2 mit mySQL$ wird als virtual machine unter
VMwarePlayer installiert. Das reicht. Wenn diese Anwendung jemals
größere Bedeutung erlangen wird, dann immer noch eine Portierung nach
mySQL5 erfolgen.

Gruss
Ekkard

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Ekkard Gerlach wrote:
> Claus Reibenstein schrieb:
>
>> SELECT datEin+0 ...

> BEsten Dank! Dieses Bsp geht bei mir genauso wie in dem comment.
> Aber: im PHP-Programmcode eingebaut erweist sich dann das datEin nicht
> einmal mehr mit druckbar: echo $res[datEin] ist leer!!

Logisch. Die Spalte im Ergebnis heißt ja jetzt nicht mehr `datEin`
sondern `datEin+0`.

SELECT datEin+0 AS datEin

Funktioniert, ist aber ein häßlicher Würgaround.

> Ebenso dann die substr(....[datEin],X,Y)!

Bin ich der einzige, der es krank findet, sich das Datum erst als Zahl
geben zu lassen, um es dann mit Stringfunktionen zu verwursten?


XL

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Axel Schwenke schrieb:

>>Ebenso dann die substr(....[datEin],X,Y)!
>
> Bin ich der einzige, der es krank findet, sich das Datum erst als Zahl
> geben zu lassen, um es dann mit Stringfunktionen zu verwursten?

ich habe es so in das Format 11.01.2007 15:47:55 gebracht und
ausgegeben. Geht wohl auch einfacher, ja? ... Naja, wenn ich
berufs-PHP-Programmierer wäre, oder zumindest im Durchschnitt 2 Stunden
die Woche PHP pogrammieren würde, würde ich es auch eleganter lösen.

Gruss
Ekkard

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755(mysql4)

Ekkard Gerlach schrieb:
> Axel Schwenke schrieb:
>
>>> Ebenso dann die substr(....[datEin],X,Y)!
>> Bin ich der einzige, der es krank findet, sich das Datum erst als Zahl
>> geben zu lassen, um es dann mit Stringfunktionen zu verwursten?
>
> ich habe es so in das Format 11.01.2007 15:47:55 gebracht und
> ausgegeben. Geht wohl auch einfacher, ja? ...

Ja. Man könnte, wenn man ein DATUM haben will, den geeigneten DATENTYP
benutzen. Ein TIMESTAMP ist das definitiv nicht.

> Naja, wenn ich
> berufs-PHP-Programmierer wäre, oder zumindest im Durchschnitt 2 Stunden
> die Woche PHP pogrammieren würde, würde ich es auch eleganter lösen.
>
Wie Andreas schon sagte: Um PHP geht es in diesem Zusammenhang gar
nicht. Wenn man eine Datenbank meint benutzen zu müssen, dann möchte man
doch bitte auch soviel Zeit aufwenden, dass man die einfachsten Konzepte
in diesem Zusammenhang kennt. Das lässt sich bspw. durch eine Lektüre
des Handbuchs erreichen.

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

In article <45ab38b7$0$18835$9b4e6d93@newsspool4.arcor-online.net>,
Christian Kirsch writes:

>> ich habe es so in das Format 11.01.2007 15:47:55 gebracht und
>> ausgegeben. Geht wohl auch einfacher, ja? ...

> Ja. Man könnte, wenn man ein DATUM haben will, den geeigneten DATENTYP
> benutzen. Ein TIMESTAMP ist das definitiv nicht.

Ich nehme an, Du meinst DATETIME. Wenn ich es richtig verstehe,
spezifiziert beides einen sekundengenauen Punkt auf der Zeitachse, und
TIMESTAMP ist nur eine poor man's solution für das fehlende "DATETIME
DEFAULT now()", oder?

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Axel Schwenke schrieb:

> Ekkard Gerlach wrote:
>
>> Ebenso dann die substr(....[datEin],X,Y)!
>
> Bin ich der einzige, der es krank findet, sich das Datum erst als Zahl
> geben zu lassen, um es dann mit Stringfunktionen zu verwursten?

Würdest Du es weniger krank finden, diese 14-stellige Zahl durch
geeignete Rechenoperationen in ihre Bestandteile zu zerlegen und
anschließend die dabei verloren gegangenen führenden Nullen mittels
geeigneter (String-)Operationen wieder hinzuzufügen?

Gruß. Claus
--
,~°O O
O ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755(mysql4)

Claus Reibenstein schrieb:
> Axel Schwenke schrieb:
>
>> Ekkard Gerlach wrote:
>>
>>> Ebenso dann die substr(....[datEin],X,Y)!
>> Bin ich der einzige, der es krank findet, sich das Datum erst als Zahl
>> geben zu lassen, um es dann mit Stringfunktionen zu verwursten?
>
> Würdest Du es weniger krank finden, diese 14-stellige Zahl durch
> geeignete Rechenoperationen in ihre Bestandteile zu zerlegen und
> anschließend die dabei verloren gegangenen führenden Nullen mittels
> geeigneter (String-)Operationen wieder hinzuzufügen?
>
> Gruß. Claus

Ich weiß nicht, was Axel gesund findet. Ich jedenfalls halte es für
krank, etwas in einem TIMESTAMP zu speichern, was man als DATETIME braucht.

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Hi Leute

Christian Kirsch wrote:
> Claus Reibenstein schrieb:
>> Axel Schwenke schrieb:
>>> Ekkard Gerlach wrote:
>>>> Ebenso dann die substr(....[datEin],X,Y)!
>>> Bin ich der einzige, der es krank findet, sich das Datum erst als Zahl
>>> geben zu lassen, um es dann mit Stringfunktionen zu verwursten?
>> Würdest Du es weniger krank finden, diese 14-stellige Zahl durch
>> geeignete Rechenoperationen in ihre Bestandteile zu zerlegen und
>> anschließend die dabei verloren gegangenen führenden Nullen mittels
>> geeigneter (String-)Operationen wieder hinzuzufügen?
> Ich weiß nicht, was Axel gesund findet. Ich jedenfalls halte es für
> krank, etwas in einem TIMESTAMP zu speichern, was man als DATETIME braucht.

Ist es nicht eigentlich egal, in welchem Format MySQL das Datum
speichert, wenn doch eh jedesmal via date_format() das gewünschte Format
selektiert werden muss?

timestamp nur zu benutzen, wenn `... default now()` gebraucht wird,
erachte ich als ganz sinnvolle Aussage. Wobei man default now() gar nie
braucht, weil man's ja auch in der Applikation angeben kann.

Just MHO, Johannes

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Johannes Vogel schrieb:
> timestamp nur zu benutzen, wenn `... default now()` gebraucht wird,
> erachte ich als ganz sinnvolle Aussage. Wobei man default now() gar nie
> braucht, weil man's ja auch in der Applikation angeben kann.

Die beiden Lösungen sind u.U. nicht ganz gleich.
MySQL hält bei einer Transaktion den Wert von NOW() fest, auch wenn sie
länger als eine Sekunde dauert. Das gleiche Verhalten in einer
Applikation nachzuprogrammieren ist relativ aufwändig.

Grüße
Kai (Datum direkt in der Applikation angebend)

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Christian Kirsch wrote:
> Claus Reibenstein schrieb:
>> Axel Schwenke schrieb:
>>> Ekkard Gerlach wrote:
>>>
>>>> Ebenso dann die substr(....[datEin],X,Y)!

>>> Bin ich der einzige, der es krank findet, sich das Datum erst als Zahl
>>> geben zu lassen, um es dann mit Stringfunktionen zu verwursten?
>>
>> Würdest Du es weniger krank finden, diese 14-stellige Zahl durch
>> geeignete Rechenoperationen in ihre Bestandteile zu zerlegen und
>> anschließend die dabei verloren gegangenen führenden Nullen mittels
>> geeigneter (String-)Operationen wieder hinzuzufügen?
>
> Ich weiß nicht, was Axel gesund findet.
> Ich jedenfalls halte es für krank, etwas in einem TIMESTAMP zu
> speichern, was man als DATETIME braucht.

Für diese Unterscheidung hat der OP nicht genug Informationen gegeben.
Ein TIMESTAMP in MySQL ist ja eigentlich ein DATETIME mit default NOW()
für INSERT und UPDATE.


XL

Re: timestamp in mysql5: 2007-01-11 15:47:55 statt 20070111154755 (mysql4)

Claus Reibenstein <4spammersonly@web.de> wrote:
> Axel Schwenke schrieb:
>> Ekkard Gerlach wrote:
>>
>>> Ebenso dann die substr(....[datEin],X,Y)!
>>
>> Bin ich der einzige, der es krank findet, sich das Datum erst als Zahl
>> geben zu lassen, um es dann mit Stringfunktionen zu verwursten?
>
> Würdest Du es weniger krank finden, diese 14-stellige Zahl durch
> geeignete Rechenoperationen in ihre Bestandteile zu zerlegen und
> anschließend die dabei verloren gegangenen führenden Nullen mittels
> geeigneter (String-)Operationen wieder hinzuzufügen?

Zur Untermauerung meiner Ansichten mal ein paar Details:

- MySQL bearbeitet TIMESTAMP und DATETIME intern immer in der gleichen
C-struct (MYSQL_TIME aus mysql_time.h)

- auch auf Storage-Layer sind beide Spalten-Typen identisch

- insbesondere hat sich das Datenformat zwischen 4.x und 5.x *nicht*
geändert. Die Aussage "daß in mysql5 der Timestamp anders in der
Datenbank abgelegt wird" ist schlicht falsch!

- auf SQL-Ebene kennt MySQL erstmal nur die Datentypen String und Zahl.
DATE/TIME/DATETIME/TIMESTAMP werden deshalb auf SQL-Ebene immer in
einen dieser beiden Typen umgewandelt. Umgekehrt können Funktionen,
die einen dieser Typen erwarten, beide Darstellungen parsen.

- was sich von 4.x auf 5.x geändert hat, ist der Zieltyp bei der
automatischen Umwandlung (vorher numerisch, jetzt String)

- auch vorher schon konnte der Zieltyp durch den Kontext bestimmt
werden. DATETIME + 0 erzwingt z.B. die numerische Umwandlung.

- der Vorteil der numerischen Darstellung besteht darin, daß man damit
leichter rechnen kann. Allerdings hat sich das mit der Erweiterung
der Datums/Zeit-Funktionen (in 4.x) weitgehend erledigt.
Es gibt IMHO heute keine sinnvolle Verwendung mehr für das numerische
Format von DATE/TIME/DATETIME/TIMESTAMP. Alles, was man früher damit
gemacht hat, kann man heute sicherer und einfacher mit eingebauten
Funktionen erledigen.


XL