Datum?

[Oliver Gringel]

Wieso sollte das sein? Wenn weitere, in beiden Fällen identische Werte abgefragt werden, so wären diese im mathematischen Sinne bloß Konstanten und entfiehlen so bei einer Gegenüberstellung. D. h. die beiden Variablen INT und DATETIME stünden sich wieder allein gegenüber.

Ok, einfaches Beispiel: Das Abfragen der Tabellen, in denen nur das Datum gespeichert ist, dauert für INT 1s, für DATETIME 1.2s. Also ist DATETIME 20% langsamer. Kommen jetzt noch weitere Spalten hinzu, dauert das Abfragen von INT z.B. 5s, das Abfragen von DATETIME 5,2s. Damit ist DATETIME nur noch 4% lagsamer. Der absolute Geschwindigkeitsunterschied ist zwar der selbe, aber der relative ist deutlich niedriger.

 

[Lukasz]

Liebe Leute bei allem Respekt!

Mag schon sein, dass hier nicht alles so richtig ist wie das von mir kurz aus Aufregung hinkommentiert worden ist. Aber hier geht es auch nicht solch ein Benchmark anzustellen. Ihr solltet dann Schon einen vollständigen Skript in 2 Varianten der 500 Einträge ausliest umwandelt Benchmarken. Wenn man behauptet, dass da kaum ein unterschied ist, gebe ich recht. Aber ihr müsst ja das Datum auch erst umrechnen, sobald ihr die Datensätze ausliest, die von gestern sein sollten. Diese auch noch in ein ansehliches Datum verfassen wie Sonntag der 28 November 2004! Und dann macht ihr beide Scripte nur mit dem unterschied zwischen DATE und INT DATE bzw UNIX Timstamp und ihr werdet euch schon wundern.

Wie eben bereits erwähnt wurde, es geht nicht nur um das auslesen, die Daten müssen auch noch verarbeitet werden.

Nur zur Info ich habe so einen Test mit 20 Einträgen gemacht. Und da ist dann schon ein Unterschied zu merken, der nicht gerade nur ein paar miliskunden gross ist.

Gruss!

PS das auslesen geht immer gleichschnell und hängt von den Bytes der Daten ab! Wie kann man das Benchmarken und mit diesen topic vergleichen? Die Daten sind dacher noch lange nicht verarbeitet!

 

[Sicaine]

Liebe Leute bei allem Respekt!

Mag schon sein, dass hier nicht alles so richtig ist wie das von mir kurz aus Aufregung hinkommentiert worden ist. Aber hier geht es auch nicht solch ein Benchmark anzustellen. Ihr solltet dann Schon einen vollständigen Skript in 2 Varianten der 500 Einträge ausliest umwandelt Benchmarken. Wenn man behauptet, dass da kaum ein unterschied ist, gebe ich recht. Aber ihr müsst ja das Datum auch erst umrechnen, sobald ihr die Datensätze ausliest, die von gestern sein sollten. Diese auch noch in ein ansehliches Datum verfassen wie Sonntag der 28 November 2004! Und dann macht ihr beide Scripte nur mit dem unterschied zwischen DATE und INT DATE bzw UNIX Timstamp und ihr werdet euch schon wundern.

Wie eben bereits erwähnt wurde, es geht nicht nur um das auslesen, die Daten müssen auch noch verarbeitet werden.

Nur zur Info ich habe so einen Test mit 20 Einträgen gemacht. Und da ist dann schon ein Unterschied zu merken, der nicht gerade nur ein paar miliskunden gross ist.

Gruss!

PS das auslesen geht immer gleichschnell und hängt von den Bytes der Daten ab! Wie kann man das Benchmarken und mit diesen topic vergleichen? Die Daten sind dacher noch lange nicht verarbeitet!

Öhm wie wärs wenn du dich vorher mal informierst?
Zufälligerweise macht mein Bench und auch der von Oliver genau das was du willst. Einmal nimmt er nen int und wandelt ihn mit php in tag.monat.jahr um und dann einmal mit datetime und der DATE_FORMAT funktion von MySql. Der 2te Test überprüft wie lang es dauert nen Unix-Timestamp rauszuholen aus int und dann aus datetime.

Zeig mal deinen "Test".

 

[Lukasz]

Na gut kann ich den auch mal bei mir ausführen? Sorry aber der glaube ist eben mein Problem und wenn doch dann beuge ich mich! Und ich werde das Kommando zurücksenden. Ich mach mal meinen bereit der das Gegenteil beweist! Dauert dann nur so 24 Stunden aber dann ist entlich mal Ruhe oder auch nicht ;-)

Mittlerweile geht es mir aber auch schon langsam am aller wertesten vorbei. Jedem wie er es eben will. Aber ich mach das mal so dass ich mal auf meiner Seite automatisch DATE mit eintrage. Sobald sich mal 100 neue Einträge gefunden haben, werden wir mal schauen wie die realität aussieht, sobald ich 9 Stunden für Amerika abziehe etc. Bin echt schon gespannt! Mag es eben so sein, glaube es aber erst sobald ich das bei mir ausführen kann! Und dann wie gesagt bin ich der letzte der sich gegenstellt. Aber ich bin ja auch nicht der erste der das praktische vorzieht. Sehen wir auch mal ob sich leicht Ostern und Weihnachten ausrechnen lässt. Und wie praktisch die ganze Sache dann im Endeffekt ausklingt.

Wobei eins kann ich wirklich jetzt zugeben, ein Geburtsdatum von User Bsp. um zu prüfen welche User Geburtstag haben ist so einfacher und auch tehoritsch schneller. OK! Weniger schneller ist es aber denke ich sobald man prüft an welchem Wochentag er Geburtstag hat. Wiederum schneller wie Alt er wird. Also dem Sage ich nichts gegen. Dennoch bin ich überzeugt im Endeffekt mehr mit TIMESTAMP erzielen zu können. Auch in Sachen Performenz!

Um die Sache von meiner Seite abzurunden, poste ich nochmals jeder wie er es eben will. Mir selbst ist es eben egal. Für mich sind Zeitstempel parktischer und vielseitiger zu verwenden. Lassen wir das mit der Zeit mal im Vor und Nachteil liegen. Mann kann sich hier auch noch Jahre lang streiten. Ich gegen beforzuge mal weiter zu informieren. Man lernt eben nie aus, ist aber auch die andere Sache.
Ein richtiger Beweis wurde trotzt zahlreicher Mühe der hier im topic verfassten Tests noch nicht erbracht. Und das meine ich auch für beide Methoden. Das müsste dann schon ins bereits generierten kompletten Webseite zum Test gebracht werden. Was man leider noch sieht sind DB abfragen, und gut ein generiertes Datum, aber nicht eine komplexe Webanwendung. Und wie ich eben schon zu anfangs gepostet hatte. Aus 20 mal ein Pups wird ein Reiesen Furz. Aber das ist auch wieder eine andere Sache.

In einer komplexen Webanwendung gibt es eben immer wieder eine Bremse. Was so viel bedeutet wie ein Schema Bsp:
Lesen userdaten
Lesen userrabg
ermitteln ob Beitrag gelesen werden kann
auslesen der ersten 20 Beiträge nach Zeit geordnet
replacen des ersten Beitrages.
Zeit auslesen und umwandeln in das gewünschte Format
nächstes einlesen
nächstes wandeln......
....
...

Was ich damit zu Wort bringen möchte, selbst wenn wir 2000 mal etwas wandelt kommt es immer noch drauf an unter welchen Belastungen das ganze geschieht. Was wir als Endergebniss haben wollen etc. Nein Bastelt man enorme Zeitrechnungen und dann sehen wir uns dann mal die Sache an. So könnte man das ganze ermitteln.

Und am rande noch nicht ganz zu vergessen ihr vergleicht ein und das selbe Scheme da der SQL code ja genau die gleichen Wandlungen durchführt wie das mit dem zeitstempel geschieht. Im Maschinencode läuft da also nichts anderes ab. Und deswegen denke ich eben an die Sache. Ein Zeitstempel ist dem Maschinencode eben ähnlicher und leichert zu wandeln. Was eigentlich schneller bedeuten sollte. Dacher wundert mich die Praxis!
Eben deswegen bin ich dafon überzeugt, denn wir rechnen im Maschinencode, und nicht in dem wie wir es uns vorstellen. Es kann natürlich auch sein, dass Mysql das besser (weniger schlampig) umrechnet und dacher näher dran ist, aber dann sollten wir auch verschiedene Versionen sowohl von mysql als auch von PHP testen. Zudem sollte man an Computern testen die wenig leistung bringen. Das ist eben die andere Sache. Denn ein Rechner von 512 MB Ram macht sich da sicher kein grossen Unterschied, zumal da der Speicher nicht einmal vollläuft. Nein die Praxis ist mit so einem Test noch nicht bewiesen. Deswegen halt mein Beitrag und harten Operationen testen. Und nicht immmer nach einem und dem selben Schema wod der PC in Wurzel umrechnen kann. Nein das ist nicht die Sache die hier zu ermitteln gillt. So ein test wäre mal auf grossrechnern wie hier oder Riesenrechnern wie Ebay ganz gut zu testen. Aber nicht hier so wo es eine paar milisekunden hin oder her geht.

Und dann wäre da noch die letzte Sache. Das Datum in der Mysql ist bereit formatiert, während ein Zeitstempel unformatiert ist. Egal ob die SQL erledigt oder nicht. Der PC rechnet dennoch mit einem Zeitstempel, mögen wir es auch leiber anders haben, aber genau das geschieht im hintergrund. Also was bringt uns darum zu streiten? DATE in mysql ist bereits formatiert, und muss dacher beim eintragen und beim auslesen rück formatiert werden um es zu berechnen. Also wenn da schon einer postet, dass ich keine Ahnung habe, bitte. Aber dann soll er das auch mal beweisen. Und wie gesagt, ich bin der letzte der dann die auch nicht animmt.


Grüsse!

 

[hpvw]

Bitte bei der Beschreibung von [phpf]strftime[/phpf] wenigstens mal den ersten Satz durchlesen, danke

Ok, Du sprichst wieder die Lokalisierung an.
Es ist (zugegeben etwas umständlicher) auch in MySQL möglich, wenn man das Query entsprechend dem einen Kommentar in der MySQL-Doku zusammensetzt.
Der Performanceunterschied scheint nach den bisher geposteten Tests sehr davon abzuhängen, was man genau will und ist (für Datenbanken der Größenordnung, wie ich sie verwende) zu vernachlässigen.
Da weder die Lokalisierung, noch die Performancefrage (hier) für mich eine Rolle spielen und ich das Datum in der Regel als 2004-12-17 (in der Syntax ist es nämlich eindeutig, im Gegensatz zu anderen Trennzeichen wie Slash und Punkt) ausgebe und es mir wichtig ist, dass in einer Datenbank ein Datum auch als solches gekennzeichnet ist, werde ich bei DATETIME bleiben.
Im Übrigen sehe ich in der Lokalisierung nicht nur Vorteile. Stell Dir mal vor, ich schreibe in einem Beitrag: "Schau doch mal in meinem Beitrag von 12 Uhr". Das ganze ohne zu wissen, dass Du in einer anderen Zeitzone sitzt und der Server lokalisiert. Ich habe um 11, um 12 und um 13 Uhr Beiträge geschrieben.
Ist schon erstaunlich, dass eine scheinbar so harmlose Frage einen Glaubenskrieg über 4 Seiten (und ich bin mir sicher, es werden noch mehr) auslöst.
Gut, dass wir mal drüber geredet haben. Wir haben eine Menge Argumente für beide Varianten gehört. Ich denke ausreichend, dass sich jeder seine eigene Meinung bilden kann. Viele Wege führen nach Rom und eben auch zur Datumsausgabe.
Ich werde die INT-Fraktion also akzeptieren(, bis ich mit einem INT-Befürworter eine gemeinsame Datenbank aufsetzen muss, dann gibts nochmal mächtig Diskussion ).
Beste Grüße
hpvw

 

[Lukasz]

OK ich denke das kann man so stehen lassen

 

[Sicaine]

@Lukaz ich werde dich jetzt einfach ignorieren aus folgenden Gründen:
Deine Rechtschreibung wie deine Grammatik ist furchtbar. Da du in deiner Signatur auch nix von legasthenie etc. geschrieben hast, muss ich davon ausgehen, dass du dich überhaupt nicht beim schreiben bemühst. dacher anstatt daher, befor anstatt bevor. Deine Sätze versteht man teilweise erst nach dem 2ten oder 3ten lesen.

Ich gegen beforzuge mal weiter zu informieren.

Du hast keine Ahnung was du schreibst. Wir müssen hier überhaupt nichts mit einer echten Website Benchen. Es reicht völlig diese kurzen teile zu benchen weil es ja darum geht was ist schneller davon. Und es ist dermasen egal ob nun der PC ein 486er oder ein 10TeraHerz CPU hat oder 1mb Ram oder 1 Gig ram.

Und nebenbei deine "5te November 2004" schreibweise ist so gut wie überhaupt nicht verbreitet weshalb das auch eher zu dein Einzelfällen gehört und wo man dann halt einfach bisl spielen muss in mysql wie auch in php.

Hättest du diese Diskussion auch aufmerksam verfolgt, wüsstest du auch, dass MySql das ganze als 64bit Integer speichert. Oder hast du etwa wirklich gedacht die speichern '2004-11-28 12:12:12' so ab?

 

[Sicaine]

und es mir wichtig ist, dass in einer Datenbank ein Datum auch als solches gekennzeichnet ist, werde ich bei DATETIME bleiben.

Da schliese ich mich einfach mal 100% an und will ihn nur kurz noch umändern:

und es mir wichtig ist, dass in einer Datenbank ein Datum auch als solches gekennzeichnet und im passendem Format gespeichert ist, werde ich bei DATETIME bleiben.