Datum?

[TheLightning]

@Johannes
Halt ma stop...
die Aussage der Benchmarks war... INT lässt sich schneller eintragen... aber DATETIME schneller Ausgeben!

Ganz nebenbei argumenierst du immer noch damit das du mit dem Timestamp rechnen möchtest dabei ist bestimmt schon 10 mal geschrieben worden das DATETIME auch einen UNIX-Timestamp zurückliefern kann...

wir waren längst an dem Punkt wo es rein um die Benchmarks ging...
ich hab hier leider auf der Arbeit keinen Apache den ich ansprechen kann... es wär nämlich mal interessant mit dem AB mal Massenanfragen zu simulieren und zu sehen wie die Rechenlast dann so aussieht.. wann geht mysql/php früher in die Knie?

Das Bezieht sich natürlich auf die Aussage INT ist bei großen Datenmengen vorzuziehen... ich denk hier muss man abwägen ob viele Daten/viele Anfragen oder beides... aber das müsste mal jemand simulieren..

Testfälle sollten dann sein:
1. timestamp über int
2. timestamp über datetime
3. datetime vorformatiert
4. date + time vorformatiert

a) eintragen
b) einen speziellen datensatz auslesen
c) daten eines zeitraums auslesen (ohne index sonst is es nich lustig )

MfG Dominik (ich würds ja machen aber ich komm hier nur mit http raus..)

 

[JohannesR]

Was war die Kernaussage von mir?

Man verwendet keinen Int für einen Timestamp.

Weil man dafür(wenn man schon ne Timestamp speichen will) den Timestamp Typ verwendet. Der in Mysql zusatzfunktionen hat.

MySQL-Timestamp != Unix-Timestamp

Ansonsten war meine 2te Aussage: Dass Datetime wesentlich besser ist als ein Timestamp.

Das kann man nicht pauschalisieren. Das muesstes langsam sogar du verstanden haben.

Und nochmal: Da meistens das formatierte Ausgeben eines Zeitpunktes das häufigste Anwendungsgebiet ist, sehe ich Datetime als standard an. Wennman nicht grad ein Script schreibtw as zig datumsberechnungen drinnen hat.

Mehr hab ich doch auch nicht gesagt? So langsam verzweifel ich.

TheLightning: Natuerlich kann Datetime auch einen Unix-Timestamp zurueckgeben, wenn man sich den Umrechenweg leisten kann und will, koennt ihr das von mir aus tun. Ich empfinde es als relativ unnoetig, fuer meine Belange zumindest. Ausserdem koennte man sonst ja auch per explode und mktime den MySQL-Datetime-Eintrag in einen Timestamp umrechnen. Wuerde man auch nicht ohne weiteres tun.

 

[TheLightning]

Also.. ich weiß nicht ganz wo dein Problem ist.. das ist keine aufwendige "umrechnung"... durch UNIX_TIMESTAMP() wird eine addition oder subtraktion (frag mich jetzt net genau) ausgeführt die die Verschiebung zum MySQL Timestamp (der soweit ich weiß auch sekundenweise zählt) ausgleicht.. das ist die simpelste operation die ein Rechner durchführen kann und benötigt (bei einer heutigen CPU mit Pipelines) auf die eine unendliche Rechnerlaufzeit umgerechnet.. durchschnittlich 1 Takt und glaub mir.. das ist selbst bei über 1000 anfragen in 1 Sekunde für den Rechner leicht zu bewerkstelligen (da wird vorher wenn der MySQL-Server aufgrund der Anzahl der Querys zusammenbrechen)...

Also nochmal.. ein Benchmark für Massenanfragen müsste her.. dann sehen wir in welchem Fall was gut ist.. ich denke das ist absolut Fallabhängig..
Stellt euch mal net auf stur sondern TESTET was wirklich in welchem Fall effektiver ist!

MfG Dominik

 

[JohannesR]

Hallo? Willst du mich veraeppeln? Wenn man ein Datetime in einen Unix-Timestamp umwandeln will ist das keine einfache Addition, sondern eine mehrfache Multiplikation, mehrere Additionen und Fallunterscheidungen. Denk mal drueber nach, wie man aus einem 2004-12-12 17:00:00 einen Unix-Timestamp machen kann!

 

[TheLightning]

Glaubst du wirklich das mysql das in dieser Form abspeichert?...
Das ist die (interne) Ausgabe davon - einen Float siehst du ja auch nicht in der form wie er abgespeichert wird.. ich bin mir jetzt zwar nicht 100%igsicher.. aber die Umwandlung von MySQL zu UNIX-Timestamp ist wohl nicht wirklich rechenintensiv!

 

[Matthias Reitinger]

Glaubst du wirklich das mysql das in dieser Form abspeichert?...
Das ist die (interne) Ausgabe davon - einen Float siehst du ja auch nicht in der form wie er abgespeichert wird.. ich bin mir jetzt zwar nicht 100%igsicher.. aber die Umwandlung von MySQL zu UNIX-Timestamp ist wohl nicht wirklich rechenintensiv!

Na wenn du dich da mal nicht täuschst...

Eine MyISAM-Tabelle mit einem DATETIME-Feld mit einer Tabellenzeile (DATETIME-Wert für 17.12.2004 13:50:58) sieht so aus:

FF D2 D1 A0 35 3A 12 00 00
|  \__________ __________/
|             v
|  64-Bit-Integer, als Dezimalzahl:
|     20041217135058
v
nicht relevant

Wie du das in den zugehörigen Unix-Timestamp in einem Takt umrechnest... das musst du mir mal zeigen.

 

[Gumbo]

Und ich kann mich nur wiederholen: In MySQL ist es klasse, wenn man mit den Zeitfunktionen rumrechnen kann, sobald man aber in einer anderen Sprache etwas damit rumbasteln will (IN PHP), ist ein Unix-Timestamp um laengen besser...

Hast du ein anwendungsnahes Beispiel? Was ließe sich denn nur mit PHP besser berechnen?

 

[Matthias Reitinger]

Hast du ein anwendungsnahes Beispiel? Was ließe sich denn nur mit PHP besser berechnen?

Ich hoffe mal, dass Johannes es mir nicht übel nimmt, wenn ich darauf antworte... aber: http://de.php.net/strftime

 

[TheLightning]

Ok.. da hab ich mich wohl getäuscht.. kann jedem mal passieren

Trotzdem ist die frage immer noch offen welches Format für welche Anforderungen und für welche selects besser geeignet ist..

Die bisherigen Benchmarks beziehen sich immer auf Einzelabfragen.. wer weiß auf was die funktion UNIX_TIMESTAMP() optimiert worden ist.. cpulast oder geschwindigkeit?

MfG Dominik

 

[hpvw]

Ich hoffe mal, dass Johannes es mir nicht übel nimmt, wenn ich darauf antworte... aber: http://de.php.net/strftime

Das hatten wir auf Seite 2 auch schon in MySQL (DATE_FORMAT)