MySQL Timestamp

[T-Rex]

Moin,

am Wochenende wollte ich folgende Abfrage machen:
"select * from tabelle where datum = timetamp"
Es lieferte mir 0 Ergebnisse zurück. Am Anfang war ich etwas schockiert, hab dann aber in der super Doku von MySQL nachlesen können das Timestamp abfragen anscheinend nicht akzeptiert werden.
Type Timestamp

Jetzt habe ich gehofft, dass mir die Experten unter euch vielleicht doch eine Möglichkeit zeigen können, das obige Abfrage funktioniert. Vielleicht gibt es irgendeine Configuration die man vor jeder Anweisung abschicken kann:
"set timestampmodus=on;
select * from tabelle where datum = timetamp"

Achja, es ist mir bewusst dass es Funktionen gibt, welche Timestamp in das gewünschte Format umwandeln. Ich müsst ein meinem System aber einiges umbauen. Es wäre erheblich leichter das ganze nur über Timestamp zu lösen.

Gruß
GMT-Rex

[suit]

am Wochenende wollte ich folgende Abfrage machen:
"select * from tabelle where datum = timetamp"
Es lieferte mir 0 Ergebnisse zurück. Am Anfang war ich etwas schockiert, hab dann aber in der super Doku von MySQL nachlesen können das Timestamp abfragen anscheinend nicht akzeptiert werden.+

Gibts denn in der Tabelle "tabelle" Datesätze deren Feld "datum" exakt mit dem Feld "timestamp" übereinstimmt?

Type Timestamp

Deine Abfrage ist syntaktisch völlig in ordnung - und die von dir verlinkte Doku-Seite dreht sich um ein völlig anderes Thema.

Jetzt habe ich gehofft, dass mir die Experten unter euch vielleicht doch eine Möglichkeit zeigen können, das obige Abfrage funktioniert.

Sie funktioniert doch.

Vielleicht gibt es irgendeine Configuration die man vor jeder Anweisung abschicken kann:
"set timestampmodus=on;

?

Achja, es ist mir bewusst dass es Funktionen gibt, welche Timestamp in das gewünschte Format umwandeln. Ich müsst ein meinem System aber einiges umbauen. Es wäre erheblich leichter das ganze nur über Timestamp zu lösen.

Was zum Teufel hast du vor?

hast du im Feld "datum" einen time_t-Wert stehen und willst diesen in eine menschenlesbare Form konvertieren?

Dann ist diese Seite der Doku ggf. hilfreicher - und natürlich ein paar Grundlagen zum Thema SQL.

[dedlfix]

Tach!

am Wochenende wollte ich folgende Abfrage machen:
"select * from tabelle where datum = timetamp"
Es lieferte mir 0 Ergebnisse zurück. Am Anfang war ich etwas schockiert, hab dann aber in der super Doku von MySQL nachlesen können das Timestamp abfragen anscheinend nicht akzeptiert werden.

Bitte beschreib nachvollziehbarer, was du da genau vorliegen hast. Was ist datum und was ist timestamp? Man muss ja schon zwischen MySQL-Timestamp und einem Unix-Timestamp unterscheiden. Obwohl auch MySQL vermutlich denselben Integerwert zum Speichern eines Timestamps verwendet, ist doch die Präsentation nach außen hin wie bei DATETIME. Auch kann man Datumswerte als String oder in MySQLs DATE(TIME)-Typen ablegen. Es gibt also einige Konstellationen, die sich ungünstig auswirken können.

dedlfix.

[suit]

Obwohl auch MySQL vermutlich denselben Integerwert zum Speichern eines Timestamps verwendet [...]

Da gibts schon einige Probleme - time_t und das was MySQL als Unix-Timestamp bezeichnet weichen voneinander ab - allein die Vorzeichen-Geschichte schränkt den praktisch nutzbaren bereich auf die Hälfte ein.

[T-Rex]

Auszug der Tabelle:

CREATE TABLE IF NOT EXISTS TABELLE (
    DATUM TIMESTAMP NOT NULL DEFAULT 0,
) ENGINE = MyISAM DEFAULT CHARSET = utf8;

Hab Daten manuell hinzugefügt. Jetzt will ich eine Abfrage machen:
select * from TABELLE where DATUM = '1314023762' -> 0 Ergebnisse (falsch)
select * from TABELLE where DATUM = '2011-08-22 16:36:02' -> 2 Ergebnisse (richtig)

Das der Timestamp umgewandelt werden müsste stellt mich vor ein paar Probleme.

Gruß
T-Rex am 1321265146

[dedlfix]

Tach!

CREATE TABLE IF NOT EXISTS TABELLE (
    DATUM TIMESTAMP NOT NULL DEFAULT 0,
) ENGINE = MyISAM DEFAULT CHARSET = utf8;

Aha, ein MySQL-Timestamp. Der, wie gesagt, sieht nach außen hin wie ein normaler Zeitwert aus.

Hab Daten manuell hinzugefügt. Jetzt will ich eine Abfrage machen:
select * from TABELLE where DATUM = '1314023762' -> 0 Ergebnisse (falsch)

Das ist ein Unix-Timestamp und der muss in einen "richtigen" Zeitwert umgerechnet werden: UNIX_TIMESTAMP() und FROM_UNIXTIME() oder so ähnlich heißen die Funktionen.

dedlfix.

[T-Rex]

Das ist ein Unix-Timestamp und der muss in einen "richtigen" Zeitwert umgerechnet werden: UNIX_TIMESTAMP() und FROM_UNIXTIME() oder so ähnlich heißen die Funktionen.

dedlfix.

Tja und genau da liegt mein Anliegen.
Meine MySQL Query Klasse hat im Moment keine Abfrage welche Art von Wert ich übergebe. Das sieht im Moment so aus
$objQuery->add("FELDNAME","=",$intTimestamp);
Dann wird mir je nachdem ein Select oder ein insert oder ein update Befehl zusammen gebaut (je nachdem was ich möchte). Ich müsste das in der Methode also umbauen:
if(timestamp)
{
  timestamp in richtiges format umwandeln || oder mysql timestamp umwandeln funktion dran hängen
} else {
mach das
}

Und genau diese Abfrage wollte ich mir ersparen, falls das irgendwie geht und ich mysql sagen kann "heys vorsicht, ich arbeite mit Timestamps". Ich hab dummerweise angenommen das Timestamp Felder mit Timestamps klar kommen :D.

Gruß
T(imestamp)-Rex

[suit]

Und genau diese Abfrage wollte ich mir ersparen, falls das irgendwie geht und ich mysql sagen kann "heys vorsicht, ich arbeite mit Timestamps". Ich hab dummerweise angenommen das Timestamp Felder mit Timestamps klar kommen :D.

Unix-Timestamps (time_t) sind (vorzeichenbehaftete) Ganzzahlen - der richtige Datentyp dafür ist Integer.

TIMESTAMP ist in MySQL nur ein Alias für den Datentyp DATETIME und hat mit einem Unix-Timestamp - mit Ausnahme, dass es ein Format zum speichern von Zeitpunkten ist - nicht viel zu tun.

Konvertieren ist aber möglich - mit einigen signifikanten Nachteilen - die entsprechende Doku-Seite hab' ich bereits verlinkt, die passenden Funktonen hat dedlfix bereits genannt.

[T-Rex]

TIMESTAMP ist in MySQL nur ein Alias für den Datentyp DATETIME und hat mit einem Unix-Timestamp - mit Ausnahme, dass es ein Format zum speichern von Zeitpunkten ist - nicht viel zu tun.

Also ich hab gelesen, das Timestamp die Werte mit 4 Byte speichert und Datetime mit 8 Byte. Deswegen bin ich von mehr als einem Alias ausgegangen. Na dann muss ich eben eine Abfrage mit einbauen :( schade...

Gruß und Danke
MySQL neu erfindener
T-Rex

[suit]

Also ich hab gelesen, das Timestamp die Werte mit 4 Byte speichert und Datetime mit 8 Byte.

Wenn deine MySQL-Version 7 Jahre alt ist, kann das stimmen :)
<http://dev.mysql.com/doc/refman/5.1/de/timestamp-4-1.html

Deswegen bin ich von mehr als einem Alias ausgegangen. Na dann muss ich eben eine Abfrage mit einbauen :( schade...

Und in Zukunft behirnen, die richtigen (oder die falschen) Datentypen konseqent zu verwenden und keinen Mischbetrieb zu praktizieren.

[T-Rex]

Also ich hab gelesen, das Timestamp die Werte mit 4 Byte speichert und Datetime mit 8 Byte.

Wenn deine MySQL-Version 7 Jahre alt ist, kann das stimmen :)
<http://dev.mysql.com/doc/refman/5.1/de/timestamp-4-1.html

Deswegen bin ich von mehr als einem Alias ausgegangen. Na dann muss ich eben eine Abfrage mit einbauen :( schade...

Nö steht in einem aktuellen neuen MySQL Performance Buch drin (Auflage 2009 oder 2010). Von alten Versionen ist da auch nicht die rede, sondern eben von einem Performance Trick. Die MySQL Dokumentation sagt das gleiche:
Data_Type_Storage_Requirements

Und in Zukunft behirnen, die richtigen (oder die falschen) Datentypen konseqent zu verwenden und keinen Mischbetrieb zu praktizieren.

Ich habe keinen Mischbetrieb, deswegen will ich ja jetzt auch nicht auf integer gehen.

Trotz allem bin ich jetzt sehr verwirrt.
Deine Beiträge lese ich nie wieder *bätsch* :P.

Gruß
xeR-T

[dedlfix]

Tach!

Also ich hab gelesen, das Timestamp die Werte mit 4 Byte speichert und Datetime mit 8 Byte.
Wenn deine MySQL-Version 7 Jahre alt ist, kann das stimmen :)
http://dev.mysql.com/doc/refman/5.1/de/timestamp-4-1.html

Es stimmt auch in aktuellen Versionen oder das Handbuch des Nachfolgers der aktuellen Version wäre schon nicht mehr aktuell.

Deswegen bin ich von mehr als einem Alias ausgegangen. Na dann muss ich eben eine Abfrage mit einbauen :( schade...
Und in Zukunft behirnen, die richtigen (oder die falschen) Datentypen konseqent zu verwenden und keinen Mischbetrieb zu praktizieren.

Einen Mischbetrieb kann man schlecht vermeiden, wenn man PHP verwendet, denn da hat man Unix-Timestamps. Die Kommunikation mit MySQL verlangt immer eine Umwandlung, entweder auf MySQL-Seite oder auf PHP-Seite.

dedlfix.

[suit]

Einen Mischbetrieb kann man schlecht vermeiden, wenn man PHP verwendet, denn da hat man Unix-Timestamps. Die Kommunikation mit MySQL verlangt immer eine Umwandlung, entweder auf MySQL-Seite oder auf PHP-Seite.

Ich glaube du hast mich missverstanden:

TIMESTAMP unter MySQL verhält sich wie DATETIME (nur der Wertbereich ist eingeschränkt) - das ist schon ein Mischbetrieb.

Entweder man arbeitet unter PHP und MySQL mit DATETIME (oder ein Derivat dessen - also besser TIMESTAMP) und nutzt unter PHP dann strftime() und strtotime() zum Konvertieren nach time()

Oder aber man nutzt time() direkt in PHP und speichert diesen als Integer in MySQL.

Ersteres hat den Vorteil, dass man sämtliche Zeitoperationen in der Datenbank machen kann, aber auf PHP-Seite erst umwursteln muss, das zweite hat den Vorteil, dass man nicht umwursteln muss, aber Datumsoperationen in PHP durchgeführt werden müssen.

Das kommt einfach auf die Datenmenge an.

[dedlfix]

Tach!

Einen Mischbetrieb kann man schlecht vermeiden, wenn man PHP verwendet, denn da hat man Unix-Timestamps. Die Kommunikation mit MySQL verlangt immer eine Umwandlung, entweder auf MySQL-Seite oder auf PHP-Seite.
Ich glaube du hast mich missverstanden:

Kann durchaus sein. Deine Aussage ließ da ja viel Spielraum.

TIMESTAMP unter MySQL verhält sich wie DATETIME (nur der Wertbereich ist eingeschränkt) - das ist schon ein Mischbetrieb.

Genauer: TIMESTAMP verhält sich in der Formatierung der Darstellung wie ein DATETIME. Ansonsten sind schon noch ein paar Unterschiede im Wertebereich und auch Verhalten vorhanden.

Entweder man arbeitet unter PHP und MySQL mit DATETIME (oder ein Derivat dessen - also besser TIMESTAMP) und nutzt unter PHP dann strftime() und strtotime() zum Konvertieren nach time()

DATETIME und TIMESTAMP kann man nicht ohne Anwendungsfall als besser oder schlechter als das jeweils andere werten. TIMESTAMP hat trotz des eingeschränkten Wertebereichs sein Einsatzgebiet mit Vorteilen gegenüber DATETIME (z.B. automatisches Ausfüllen bei Neueinträgen und Updates, also wenn man ihn wie vorgesehen als Zeitstempel und nicht als beliebigen Datumswert einsetzt).

Oder aber man nutzt time() direkt in PHP und speichert diesen als Integer in MySQL.

Das Konvertieren kann man auch mit den bereits genannten UNIXTIME-Funktionen in MySQL erledigen. Das ist meines Erachtens der effizienteste Kompromiss für beide Seiten.

Ersteres hat den Vorteil, dass man sämtliche Zeitoperationen in der Datenbank machen kann, aber auf PHP-Seite erst umwursteln muss, das zweite hat den Vorteil, dass man nicht umwursteln muss, aber Datumsoperationen in PHP durchgeführt werden müssen.

Mit Konvertierung gehen Zeitoperationen auch im DBMS. Man muss nur aufpassen, wie man die Abfrage formuliert, sonst leidet die Performance. Zum Beispiel ist jeden Feldwert umzurechnen und dann zu vergleichen ungünstiger als jeden Feldwert mit einem umgerechneten Wert zu vergleichen.

dedlfix.

[suit]

Das Konvertieren kann man auch mit den bereits genannten UNIXTIME-Funktionen in MySQL erledigen. Das ist meines Erachtens der effizienteste Kompromiss für beide Seiten.

Mit dem MySQL-Bordmitteln kastriert man sich aber möglicherweise die Daten:

http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_unix-timestamp

"Note: If you use UNIX_TIMESTAMP() and FROM_UNIXTIME() to convert between TIMESTAMP values and Unix timestamp values, the conversion is lossy because the mapping is not one-to-one in both directions. [...]"

[dedlfix]

Tach!

Das Konvertieren kann man auch mit den bereits genannten UNIXTIME-Funktionen in MySQL erledigen. Das ist meines Erachtens der effizienteste Kompromiss für beide Seiten.
Mit dem MySQL-Bordmitteln kastriert man sich aber möglicherweise die Daten:

OK, oder besser gesagt, nicht ok. Wer kam nur auf die Idee, so ein eingeschränktes Format zu erfinden? Also wenn man nicht nur 1970 bis 2037 verwalten will, dann besser in PHP formatieren und parsen. (Dass PHP 64 Bit für den Timestamp verwendet, kann auch noch nicht so lange her sein.)

dedlfix.

[suit]

OK, oder besser gesagt, nicht ok. Wer kam nur auf die Idee, so ein eingeschränktes Format zu erfinden?

Wieso? time_t ist doch völlig ausreichend für viele bereiche - einfach hochzählen und gut ist.

Für alles wo man jetzt nicht notwendigerweise Publizierungs- oder Logdaten speichern will, ist aber DATETIME ebenfalls nicht ausreichend. Bei austronomischen oder historischen Daten hast du auch schnell einen Überlauf.

[T-Rex]

Entweder man arbeitet unter PHP und MySQL mit DATETIME (oder ein Derivat dessen - also besser TIMESTAMP) und nutzt unter PHP dann strftime() und strtotime() zum Konvertieren nach time()

Wenn ich das so machen würde, dann wäre mein PHP System doch von der MySQL Datumsdarstellung abhängig? Deshalb hätte ich die Daten in meinen Klassen immer als Timestamp vorgehalten und bei Bedarf in die entsprechende Datenbanksprache konvertiert, je nachdem was da angebunden ist.
Die zwei Wege die du da beschreibst haben doch beide erhebliche Nachteile.
Wenn man alles mit Timestamps macht, dann kann man unter Umständen die Datum Funktionen von der jeweiligen Datenbank (hier MySQL) nicht ausnutzen.
Wenn man alles im MySQL Format hat, ist man von diesem Abhängig. Wenn man eine Datenbank anbindet, die dieses Format nicht unterstützt ist man wieder gea****t. Aber auch, wenn die Daten gar nicht an eine Datenbank gehen, sondern an ein PDF oder CSV Datei.

Also ich schreibe das alles, weil ich jetzt sehr unschlüssig bin, welchen Weg ich wirklich gehen möchte. Ein Mischmasch wie du es bezeichnest hätte eben die Unabhängigkeit von php und mysql. Man bräuchte nur bei Datenbank Sachen einen Konverter, der die Datumsachen in das gewünschte Format portiert.

Gruß
in Gedanken versunkene
T-Rex

[dedlfix]

Tach!

Wenn ich das so machen würde, dann wäre mein PHP System doch von der MySQL Datumsdarstellung abhängig? Deshalb hätte ich die Daten in meinen Klassen immer als Timestamp vorgehalten und bei Bedarf in die entsprechende Datenbanksprache konvertiert, je nachdem was da angebunden ist.

DBMS-Unabhängigkeit ist sowieso eine Illusion. Es finden sich immer irgendwelche DBMS-Spezifika, die man ausgerechnet nutzen möchte, weil sie komfortabel sind oder weil es wegen der Unterschiede in den SQL-Dialekten nicht anders geht. Schreib dir lieber keine DBMS-Abstraktion sondern eine Daten-Abstraktion. Dann bist du nach unten hin flexibel, was die Formulierung von SQL-Statements angeht und kannst auf die Eigenheiten der angebundenen Systeme eingehen, bist "nach oben hin", also zu deiner Geschäftslogik, trotzdem mit der gleichen Schnittstelle unterwegs. Und dann kannst du beispielsweise auch andere Datenquellen und -senken anflanschen oder auch nur für bestimmte Dinge was komplett anderes machen als mit den anderen Daten.

Wenn man alles im MySQL Format hat, ist man von diesem Abhängig. Wenn man eine Datenbank anbindet, die dieses Format nicht unterstützt ist man wieder gea****t. Aber auch, wenn die Daten gar nicht an eine Datenbank gehen, sondern an ein PDF oder CSV Datei.

Ja, genau das Problem hast du später nicht nur mit den Zeitwerten. Es garantiert dir ja noch nicht mal jemand, dass alle zukünftig vielleicht mal verwendeten Systeme überhaupt mit Unix-Timestamps zurechtkommen.

Also ich schreibe das alles, weil ich jetzt sehr unschlüssig bin, welchen Weg ich wirklich gehen möchte. Ein Mischmasch wie du es bezeichnest hätte eben die Unabhängigkeit von php und mysql. Man bräuchte nur bei Datenbank Sachen einen Konverter, der die Datumsachen in das gewünschte Format portiert.

(Mehr) Schichten bauen. Dann kann man nach oben hin und nach unten hin andere Dinge anbauen (und innerhalb der Schicht für notwendige Konvertierungen sorgen), ohne die jeweils andere Richtung zu beeinträchtigen.

dedlfix.

[T-Rex]

Danke dedlfix,

jetzt hab ich das Gefühl das ich nicht ganz doof bin :).

Gruß
IQ > RTL II Nachrichten
T-Rex

[dedlfix]

Tach!

TIMESTAMP ist in MySQL nur ein Alias für den Datentyp DATETIME und hat mit einem Unix-Timestamp - mit Ausnahme, dass es ein Format zum speichern von Zeitpunkten ist - nicht viel zu tun.
Also ich hab gelesen, das Timestamp die Werte mit 4 Byte speichert und Datetime mit 8 Byte. Deswegen bin ich von mehr als einem Alias ausgegangen.

Es ist mehr als ein Alias, was schon der unterschiedliche Wertebereich zeigt. In der Bedienung fühlt es sich aber wie ein Alias an.

dedlfix.

[dedlfix]

Tach!

Meine MySQL Query Klasse hat im Moment keine Abfrage welche Art von Wert ich übergebe. Das sieht im Moment so aus
$objQuery->add("FELDNAME","=",$intTimestamp);

Dann schlage ich vor, dass du dieses Problem generell durch Erweiterung deiner Klasse löst. Man braucht manchmal einfach Ausdrücke im Statement, die nicht wie normale Strings behandelt werden können (z.B. NOW(), und auch Schlüsselwörter wie NULL). Du könntest eine weitere Klasse erstellen, die nur als Formelaufnehmer dient. Zum Beispiel so:

$objQuery->add("FELDNAME", "=", new Ausdruck('FROM_UNIXTIME(' . $intTimestamp . ')'));

Der Konstruktor von "Ausdruck" legt den übergebenen Wert in einer internen Variable ab und gibt ihn auf Anforderung heraus. Mehr macht die Klasse nicht. Die add-Methode jedoch prüft ob ein String oder eine instanceof Ausdruck übergeben wurde und macht dann jeweils das richtige damit.

Und genau diese Abfrage wollte ich mir ersparen, falls das irgendwie geht und ich mysql sagen kann "heys vorsicht, ich arbeite mit Timestamps". Ich hab dummerweise angenommen das Timestamp Felder mit Timestamps klar kommen :D.

Vielleicht bekommst du was mit Views, auf alle Fälle aber eine Lösung mit Stored Procedure hin. Aber einfacher als die Klassenerweiterung wird das sicher nicht.

dedlfix.

[hotti]

Hmm,

hab mal den Fred gelesen. Evntl. sind folgende Hinweise noch Deiner Sache förderlich:

1. ein Feld vom Type TIMESTAMP darf es in einer Tabelle nur einmal geben
2. es ist dafür gedacht, dem Record einen Zeitstempel aufzudrücken
3. ein Insert Value() kann entfallen, wenn der DEFAULT definiert ist

CREATE...
... zeitstempel TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,

also beim Insert den Value einfach weglassen. Deine Abfragen jedoch müssen weiterhin das Format eines Datum haben (0000-00-00 00:00:00) oder Du nimmst die hier im Fred genannten DB-Funktionen.

Hotti

[ChrisB]

Hi,

1. ein Feld vom Type TIMESTAMP darf es in einer Tabelle nur einmal geben

Das ist Quatsch.

MfG ChrisB

[hotti]

hi,

1. ein Feld vom Type TIMESTAMP darf es in einer Tabelle nur einmal geben

Das ist Quatsch.

Du hast vollkommen Recht, ich hab Blödsinn geschrieben. Was es nur einmal geben darf ist der Default:

DBD::mysql::st execute failed: Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause at SQL.pm line 33.

Hotti

[dedlfix]

Tach!

1. ein Feld vom Type TIMESTAMP darf es in einer Tabelle nur einmal geben

Teilweise schon geklärt. Was es nur einmal geben darf ist die mit TIMESTAMP verbundene INSERT- und UPDATE-Automatik. Andere Default-Werte als CURRENT_TIMESTAMP sind beliebig verwendbar.

2. es ist dafür gedacht, dem Record einen Zeitstempel aufzudrücken

Ja, also eher für Log-Zwecke. Die begrenzten Eigenschaften haben wir ja schon lang und breit beleuchtet. Für alles andere als Zeitstempel ist DATETIME vorgesehen.

3. ein Insert Value() kann entfallen, wenn der DEFAULT definiert ist

Das ist keine TIMESTAMP-Besonderheit. Das Ausfüllen mit dem Default-Wert bei nicht aufgeführtem Feld funktioniert mit jedem Feldtyp, der ein Default haben darf (TEXT und BLOB dürfen beispielsweise nicht).

dedlfix.

[hotti]

hi,

3. ein Insert Value() kann entfallen, wenn der DEFAULT definiert ist

Das ist keine TIMESTAMP-Besonderheit. Das Ausfüllen mit dem Default-Wert bei nicht aufgeführtem Feld funktioniert mit jedem Feldtyp, der ein Default haben darf (TEXT und BLOB dürfen beispielsweise nicht).

Ja. Bei Defaultwerten kommts darauf an, die nicht nur zu vergeben, sondern auch zu nutzen. Oder anders ausgedrückt: Wenn die DBengine einen Wert setzen kann, welcher der Anforderung genügt, muss dieser Wert nicht anderweitig ermittelt werden.

Hotti