# Datum?



## mrfishly (15. Dezember 2004)

Hallo zusammen. 

Ich hab da mal wieder ein Prob. Ich hab ein script geschrieben für screenshots hochzuladen. soweit so gut.  auch. Aber jetzt wollt ich das script noch was erweitern und sowas machen damit der User sein kommentar zu den screenshots machen kann. Nur ich frag mich wie ich jetzt das datum und die Uhrzeit des Kommentars in die datenbank bekomme.

Kurz: Wie muss ich das Feld in der datenbank deklarieren únd wie sieht der eintrag im php code aus?

Danke schonmal im Voraus. 

Fish


----------



## theCean (15. Dezember 2004)

*Re: Datum? Häääää?*

Mache einfach ein VARCHAR feld in der DB und schreibe dass date() rein!
(Nächstes mal erst suchen bitte!)


----------



## Matthias Reitinger (15. Dezember 2004)

*Re: Datum? Häääää?*

Eine Möglichkeit wäre, ein Feld vom Typ DATETIME in deiner Tabelle anzulegen. Davon rate ich dir allerdings zwecks einfacherer Weiterverarbeitung ab. Benutz stattdessen ein Feld, das einen INT-Wert aufnehmen kann. Darin speicherst du den Unix-Timestamp, der die verstrichenen Sekunden seit dem 01.01.1970 0:00 GMT angibt.

Beispiel:

```
INSERT INTO `tabelle` (`foo`, `zeit`) VALUES ('bar', UNIX_TIMESTAMP())
```

Zur Ausgabe formatieren kannst du diesen Wert dann bspw. mit der Funktion [phpf]date[/phpf].


----------



## Oliver Gringel (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				Matthias Reitinger hat gesagt.:
			
		

> Eine Möglichkeit wäre, ein Feld vom Typ DATETIME in deiner Tabelle anzulegen. Davon rate ich dir allerdings zwecks einfacherer Weiterverarbeitung ab. Benutz stattdessen ein Feld, das einen INT-Wert aufnehmen kann. Darin speicherst du den Unix-Timestamp, der die verstrichenen Sekunden seit dem 01.01.1970 0:00 GMT angibt.
> 
> Beispiel:
> 
> ...


Und warum sollte man bitte ein DATETIME-Feld nicht einfach weiterverarbeiten können. Für Datumsangaben sollte man immer DATETIME verwenden, und niemals INT.
mySQL stellt dir eine Menge Datumsfunktionen zur Verfügung, mit denen man wunderbar ein Datum verarbeiten kann (unter anderem auch eine Funktion, die dir den UNIX-Timestamp des Datums zurückgibt).

http://dev.mysql.com/doc/mysql/de/DATETIME.html
http://dev.mysql.com/doc/mysql/de/Date_and_time_functions.html


----------



## Matthias Reitinger (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				Oliver Gringel hat gesagt.:
			
		

> Und warum sollte man bitte ein DATETIME-Feld nicht einfach weiterverarbeiten können.


Weil keine einzige PHP-Funktion was mit einem DATETIME-Wert anfangen kann z.B.?  



			
				Oliver Gringel hat gesagt.:
			
		

> Für Datumsangaben sollte man immer DATETIME verwenden, und niemals INT.


Begründung?



			
				Oliver Gringel hat gesagt.:
			
		

> mySQL stellt dir eine Menge Datumsfunktionen zur Verfügung, mit denen man wunderbar ein Datum verarbeiten kann (unter anderem auch eine Funktion, die dir den UNIX-Timestamp des Datums zurückgibt).


Ist mir natürlich bekannt. Aber wozu ständig DATETIME in einen Timestamp umwandeln, wenn man doch auch gleich den Timestamp speichern kann?


----------



## Oliver Gringel (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				Matthias Reitinger hat gesagt.:
			
		

> Weil keine einzige PHP-Funktion was mit einem DATETIME-Wert anfangen kann z.B.?


Wenn du das Datum mit PHP weiter verarbeiten willst, kannst du dir es mit der Funktion UNIX_TIMESTAMP als Timestamp zurückgeben lassen. Wenn du das Datum direkt ausgeben willst, kannst du es mit der Funktion DATE_FORMAT formatieren, wie du willst.



			
				Matthias Reitinger hat gesagt.:
			
		

> Begründung?


INT ist für Zahlenwerte im Bereich von -2147483648 bis 2147483647 bzw. von 0 bis 4294967295 gedacht. DATETIME, wie der Name schon sagt, für ein Datum mit Zeitangabe, im Bereich von '1000-01-01 00:00:00' bis '9999-12-31 23:59:59'. Damit hast du eine viel größere Zeitspanne, als bei Timestamps.
Was machst du, wenn du z.B. ein Geburtsdatum vor dem 1.1.1970 ausgeben möchtest?
Und das Jahr 2037 wird auch kommen, soviel ist sicher. Bis dahin wird es wahrscheinlich keine UNIX-Timestamps mehr geben, aber es ist einfach zukunftsorientiert, auf bessere Alternativen umzusteigen 




			
				Matthias Reitinger hat gesagt.:
			
		

> Ist mir natürlich bekannt. Aber wozu ständig DATETIME in einen Timestamp umwandeln, wenn man doch auch gleich den Timestamp speichern kann?


Siehe 1. und 2. Argument.


----------



## mrfishly (15. Dezember 2004)

*Re: Datum? Häääää?*

was denn nu? raff nix mehr?!


----------



## smo da man (15. Dezember 2004)

*Re: Datum? Häääää?*

Mach aus dem Feld den Typen "DATETIME". 
Diesem brauchts du dann nur einen TIMESTAMP zu übergeben. 

Peace smo


----------



## TheLightning (15. Dezember 2004)

*Re: Datum? Häääää?*

DATETIME verwenden!

1. is es genau dafür da und von daher auch dafür optimiert
2. kannst du mit NOW() direkt im query den aktuellen timestamp setzen
3. für was willst du unbedingt den UNIX-Timestamp als Integer speichern.. dadurch muss dein Interpreter nur mehr rechnen => Performancegedanken

MfG Dominik


----------



## Matthias Reitinger (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				Oliver Gringel hat gesagt.:
			
		

> Wenn du das Datum mit PHP weiter verarbeiten willst, kannst du dir es mit der Funktion UNIX_TIMESTAMP als Timestamp zurückgeben lassen. Wenn du das Datum direkt ausgeben willst, kannst du es mit der Funktion DATE_FORMAT formatieren, wie du willst.


Ich werf nur mal das Wort "Lokalisierung" in den Raum  Damit kann DATE_FORMAT nämlich nichts anfangen.



			
				Oliver Gringel hat gesagt.:
			
		

> INT ist für Zahlenwerte im Bereich von -2147483648 bis 2147483647 bzw. von 0 bis 4294967295 gedacht. DATETIME, wie der Name schon sagt, für ein Datum mit Zeitangabe, im Bereich von '1000-01-01 00:00:00' bis '9999-12-31 23:59:59'. Damit hast du eine viel größere Zeitspanne, als bei Timestamps.


Man nehme einen 64-bittigen Timestamp und erwäge, dass man dann eine Zeitspanne von einer guten halben Billion Jahre abbilden könnte 



			
				Oliver Gringel hat gesagt.:
			
		

> Was machst du, wenn du z.B. ein Geburtsdatum vor dem 1.1.1970 ausgeben möchtest?
> Und das Jahr 2037 wird auch kommen, soviel ist sicher. Bis dahin wird es wahrscheinlich keine UNIX-Timestamps mehr geben, aber es ist einfach zukunftsorientiert, auf bessere Alternativen umzusteigen


Geht's hier um Geburtsdaten? Ich glaub nicht  Und wer im Jahr 2037 noch nicht mit 64-bit-Timestamps arbeitet, ist selber schuld


----------



## TheLightning (15. Dezember 2004)

*Re: Datum? Häääää?*

64-bittig im Integerraum ... hab ich was verpasst?


----------



## smo da man (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				TheLightning hat gesagt.:
			
		

> DATETIME verwenden!
> 
> 1. is es genau dafür da und von daher auch dafür optimiert
> 2. kannst du mit NOW() direkt im query den aktuellen timestamp setzen
> ...



Guten Morgen schau mal einen Post über deinem !


----------



## TheLightning (15. Dezember 2004)

*Re: Datum? Häääää?*

Ich les in deinem Post z.b. nichts von NOW().. also.. gaaanz ruhig


----------



## mrfishly (15. Dezember 2004)

*Re: Datum? Häääää?*

Ok, thanks... habs gerafft!  Und zofft euch nich soviel!


----------



## Oliver Gringel (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				Matthias Reitinger hat gesagt.:
			
		

> Ich werf nur mal das Wort "Lokalisierung" in den Raum  Damit kann DATE_FORMAT nämlich nichts anfangen.
> 
> 
> Man nehme einen 64-bittigen Timestamp und erwäge, dass man dann eine Zeitspanne von einer guten halben Billion Jahre abbilden könnte
> ...



Wie schon oft erwähnt, du kannst dir auch ein DATETIME-Feld als Timestamp zurückgeben lassen. Damit hast du alle Möglichkeiten, die du auch bei einen INT hättest. Und mit 64bit Datentypen können die PHP-Funktionen nichts anfangen. Also bringt dir das recht wenig.


----------



## Sicaine (15. Dezember 2004)

*Re: Datum? Häääää?*

@Matthiasreitinger hm du gehörst wohl auch zu diesen Typen die Bilder in die DB haun? Und womöglich haust du nen String binär in die DB.


----------



## Matthias Reitinger (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				Oliver Gringel hat gesagt.:
			
		

> Wie schon oft erwähnt, du kannst dir auch ein DATETIME-Feld als Timestamp zurückgeben lassen. Damit hast du alle Möglichkeiten, die du auch bei einen INT hättest.


Wie schon oft erwähnt, warum umrechnen, wenn man's auch gleich als Timestamp haben kann?



			
				Oliver Gringel hat gesagt.:
			
		

> Und mit 64bit Datentypen können die PHP-Funktionen nichts anfangen. Also bringt dir das recht wenig.


_Noch_ nicht... aber bis 2037 sicher...  

Na ja... ich glaub wir kommen so nicht zusammen...  Belassen wir's dabei, ich bleib bis auf weiteres bei meinen Integer-Timestamps, und du benutzt weiterhin DATETIME... so lang wir nicht mal gemeinsam an einem Projekt arbeiten, seh ich da auch keine Probleme 



			
				Sicaine hat gesagt.:
			
		

> @Matthiasreitinger hm du gehörst wohl auch zu diesen Typen die Bilder in die DB haun? Und womöglich haust du nen String binär in die DB.


1. Wo ist da der Zusammenhang zum Thema?
2. Wie kommst du auf diese abstrusen Behauptungen?


----------



## JohannesR (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				Sicaine hat gesagt.:
			
		

> @Matthiasreitinger hm du gehörst wohl auch zu diesen Typen die Bilder in die DB haun? Und womöglich haust du nen String binär in die DB.


Was soll denn dieser dumme Flame? Du hast doch schon oft genug bewiesen, dass du nichts wichtiges zu sagen hast, warum laesst du es nicht einfach, und haeltst dich aus Diskussionen raus, die dir zu hoch sind? Sonst hau ich ganz was anderes wohin. *kopfschuettel*
Achja, mrfishly: Achte dringend auf deine Rechtschreibung und die Struktur deiner Beitraege, die sind naemlich ziemlich... chaotisch?


----------



## Sicaine (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				Johannes Röttger hat gesagt.:
			
		

> Was soll denn dieser dumme Flame? Du hast doch schon oft genug bewiesen, dass du nichts wichtiges zu sagen hast, warum laesst du es nicht einfach, und haeltst dich aus Diskussionen raus, die dir zu hoch sind? Sonst hau ich ganz was anderes wohin. *kopfschuettel*
> Achja, mrfishly: Achte dringend auf deine Rechtschreibung und die Struktur deiner Beitraege, die sind naemlich ziemlich... chaotisch?


Wo hab ich nix wichtiges zusagen? Wo flame ich rum?

@Matthias ganz einfach wenn ich ein Datum in ne db speichere dann auch mit dem richtigen typ. Und der is halt nich int sondern Date oder halt Datetime.


----------



## hpvw (15. Dezember 2004)

*Re: Datum? Häääää?*

Wozu braucht man denn in einer Datenbank eine Lokalisierung?
Da steht eindeutig und ganz genau drin, zu welchen Zeitpunkt nach Serverzeit das Datum gesetzt wurde.
Etwas anderes ist in der Datenbank nicht vernünftig, da Du Dir sonst bei jedem Auslesen überlegen mußt, in welcher Zeitzone Du das Datum haben willst UND in welcher Zeitzone es gespeichert wurde.

Außerdem entspricht das Datum als DATETIME der ISO-Norm, im Gegensatz zu einem INT.

Man kann ja auch INT's als CHAR und Strings in einem BLOB ablegen, aber wozu?

Gruß hpvw


----------



## Matthias Reitinger (15. Dezember 2004)

Leute... wenn ihr mich nicht versteht, lasst es einfach   Ich hab keine Lust, hier alles doppelt und dreifach hinzuschreiben, wenn's dann doch wieder überlesen wird...


----------



## JohannesR (15. Dezember 2004)

*Re: Datum? Häääää?*



			
				Sicaine hat gesagt.:
			
		

> Wo hab ich nix wichtiges zusagen? Wo flame ich rum?


Tut mir leid, derart dumme Fragen beantworte ich nicht. Aber ich gebe dir einen kleinen Hinweis: Achte auf den Kram um die Frage mit dem Bild in der Datenbank.



> @Matthias ganz einfach wenn ich ein Datum in ne db speichere dann auch mit dem richtigen typ. Und der is halt nich int sondern Date oder halt Datetime.


Ja, und wenn man einen Timestamp in der Datenbank speichern will, ist nunmal ein Integer der richtige Datentyp. Nun muss man sich entscheiden, was man will... Wenn man viel ueber das SQL-Statement filtern oder selecten will, ist ein Date(time) sicher nicht die falsche Wahl, wenn man aber vor allem das Datum auslesen will, und damit in PHP wilde Dinge anstellen will (Wochentag rausfinden, Kalenderwoche, etc. pp.) ist ein Timestamp einfach viel komfortabeler. *kopfschuettel* So schwer ist das doch nicht, oder?


----------



## Gumbo (15. Dezember 2004)

Würdet ihr bitte die Zeitstempel, welche den vergangenen Sekunden seit dem Beginn der „Unix-Epoche“, auch als solche kenntliche machen, z. B. durch den Begriff „Unix-Zeitstempel“. Denn auch MySQL besitzt einen „Zeitstempel“.


Um mich auch noch in die Diskussion einzumischen: Die MySQL-Funktion DATE_FORMAT() verfügt über ähnliche Spezifikatoren wie die PHP-Funktion date(). Somit ist die Behauptung, dass nur mit PHP solche wilden Dinge anzustellen wären, eher gehaltlos.
Ok, wenn ich ein Datumsformat entsprechend den RFC 2822 oder den ISO 8601-Spezifikationen benötige, ist die date()-Funktion natürlich vorteilhafter.


----------



## Sicaine (15. Dezember 2004)

```
Specifier 	 Description
%a 	Abbreviated weekday name (Sun..Sat)
%b 	Abbreviated month name (Jan..Dec)
%c 	Month, numeric (0..12)
%D 	Day of the month with English suffix (0th, 1st, 2nd, 3rd, ...)
%d 	Day of the month, numeric (00..31)
%e 	Day of the month, numeric (0..31)
%f 	Microseconds (000000..999999)
%H 	Hour (00..23)
%h 	Hour (01..12)
%I 	Hour (01..12)
%i 	Minutes, numeric (00..59)
%j 	Day of year (001..366)
%k 	Hour (0..23)
%l 	Hour (1..12)
%M 	Month name (January..December)
%m 	Month, numeric (00..12)
%p 	AM or PM
%r 	Time, 12-hour (hh:mm:ss followed by AM or PM)
%S 	Seconds (00..59)
%s 	Seconds (00..59)
%T 	Time, 24-hour (hh:mm:ss)
%U 	Week (00..53), where Sunday is the first day of the week
%u 	Week (00..53), where Monday is the first day of the week
%V 	Week (01..53), where Sunday is the first day of the week; used with %X
%v 	Week (01..53), where Monday is the first day of the week; used with %x
%W 	Weekday name (Sunday..Saturday)
%w 	Day of the week (0=Sunday..6=Saturday)
%X 	Year for the week where Sunday is the first day of the week, numeric, four digits; used with %V
%x 	Year for the week, where Monday is the first day of the week, numeric, four digits; used with %v
%Y 	Year, numeric, four digits
%y 	Year, numeric, two digits
%% 	A literal `%'.
```

Öhm ja sicher alles klar...
Wir ignoieren bitte einfach die oben verfügbaren Möglichkeiten mit Mysql ein Datum zu formatieren @Johannes Röttger


----------



## hpvw (15. Dezember 2004)

Dann will ich nochmal ein weiteres Argument in den Raum werfen:
Eine Datenbank soll Daten in strukturierter Form speichern.
Dabei spielt es keine Rolle, mit welcher Programmiersprache oder Anwendungssoftware ich auf diese Daten zugreife.
Ich könnte jetzt nicht mit Sicherheit eine Programmiersprache nennen, mit der man keinen UNIX-Timestamp bearbeiten kann, aber ich bin mir sicher, dass eine gibt.
Außerdem muss es in anderen Sprachen lange nicht so komfortabel sein, damit umzugehen.
Als kleines Beispiel einer Anwendung, die übrigends in PHP geschrieben ist, will ich mal phpMyAdmin nennen, ein sicherlich von vielen PHP-Datenbankprogrammieren genutztes Tool.
Hiermit die Eingaben in einem INT-Feld zu überprüfen dürfte schwierig werden.
Vielleicht fällt einem ja irgendwann mal ein, eine "Offline-Version" zum Zugriff auf die Datenbank zu schreiben, oder man stellt seine Seite irgendwann auf JSP um oder ... oder ... oder...
Aus gutem Grund gibt es bei Anwendungsentwicklung die Trennung in verschiedene Schichten.

Gruß hpvw


----------



## TheLightning (16. Dezember 2004)

*Re: Datum? Häääää?*



			
				Johannes Röttger hat gesagt.:
			
		

> Ja, und wenn man einen Timestamp in der Datenbank speichern will, ist nunmal ein Integer der richtige Datentyp. Nun muss man sich entscheiden, was man will... Wenn man viel ueber das SQL-Statement filtern oder selecten will, ist ein Date(time) sicher nicht die falsche Wahl, wenn man aber vor allem das Datum auslesen will, und damit in PHP wilde Dinge anstellen will (Wochentag rausfinden, Kalenderwoche, etc. pp.) ist ein Timestamp einfach viel komfortabeler. *kopfschuettel* So schwer ist das doch nicht, oder?



Dir ist schon klar das du dir auch bei DATETIME als Timestamp eingeben und zurückgeben lassen kannst oder?..
Warum ist Integer dann die bessere Methode?!
Integer ist:
1. nicht so komfortabel (z.b. diverse Möglichkeiten beim Filtern die man natürlich aber auch mit "Workarounds" mit PHP und Integer nachstellen kann)
2. nicht dafür gedacht (und entsprechend nicht dafür Optimiert)
3. du hast mit DATETIME alle möglichkeiten die bei Integer möglich sind (und Datumsrelevant sein könnten)

MfG Dominik


----------



## Lukasz (16. Dezember 2004)

Ich gebe da Matthias Reitinger vollkommen Recht! Wir war das mit dem Zeitstempel Problem um das Jahr 2ooo ein Theater und kaum was hat nicht getan.

Man sollte das auch in einem INT Feld deffinieren, weil nur so Beispielweise ORDER BY DATUM DESC auch garantiert ist, dass alte Daten in der Richtigen Reihenfolge ausgegeben werden. Mit Varchar gibt es Probleme. TIME ist eigentlich für EXEL etc praktisch aber leider nicht in PHP. PHP rechnet diesen Code sowieso erst in einen Zeitstempel um, zuvor es weiterverarbeitet werden kann, und dann ist es parktischer und schneller das ganze mit einem Zeitstempel einzutragen. Es reicht hier aber auch TIME()

INSERT INTO tabelle (datum) VALUES (time())

Gruss

PS mann kann sich natürlich darüber streiten, aber dabei sollte man nur praktisch denken. Jeder Computer rechnet Zeitstempel. Daten werden öfters ausgelesen wie eingetragen. Natürlich geht das wandeln schnell, aber wer schon grosse Seiten geschrieben hat, der weis das aus 20 mal ein kleiner Pups ein riesen Fruz entsteht   bekanntlich dauert dies lange und es stinkt dann auch!


----------



## Sicaine (16. Dezember 2004)

Lukasz hat gesagt.:
			
		

> Ich gebe da Matthias Reitinger vollkommen Recht! Wir war das mit dem Zeitstempel Problem um das Jahr 2ooo ein Theater und kaum was hat nicht getan.
> 
> Man sollte das auch in einem INT Feld deffinieren, weil nur so Beispielweise ORDER BY DATUM DESC auch garantiert ist, dass alte Daten in der Richtigen Reihenfolge ausgegeben werden. Mit Varchar gibt es Probleme. TIME ist eigentlich für EXEL etc praktisch aber leider nicht in PHP. PHP rechnet diesen Code sowieso erst in einen Zeitstempel um, zuvor es weiterverarbeitet werden kann, und dann ist es parktischer und schneller das ganze mit einem Zeitstempel einzutragen. Es reicht hier aber auch TIME()
> 
> ...



Den ersten Satz verstehe  ich nicht wirklich. Aber ich geh mal davona us, dass du irgendwas mit dem Jahr 2000 Problem meinst? Dir ist klar wie Datetime das Datum speichert? Da gibt es keine Probleme.

VarChar hat wohl überhaupt garnichts mit nem Timestamp zu tun.

Order By funktioniert hier genauso gut wie mit nem Timestamp in nem Intfeld.

Ansonsten: schön ich gebs 20 mal aus aber ich gebe es Formatiert aus! Es wäre was anders wenn ich es 20 mal zum rechnen benötigen würde. Und wer große Seiten schreibt, lernt es zu scähtzen es schnell mit DATE_FORMAt zu formatieren um es dann schnell und problemlos auszugeben. 


> der weis das aus 20 mal ein kleiner Pups ein riesen Fruz entsteht


----------



## Lukasz (16. Dezember 2004)

Siehst du da ist schon das Problem (du gibst es formaiter aus) und dies soll ich glauben?

Geschrieben am 2004-11-28 von ... echt?

Bei mir sieht das so aus
http://www.2ts2.net/index.php?&get=forum/showpost.php&thisthread_id=514&seite=10000000

Sorry ich will dich nicht angreifen man kann die Reihenfole auch drehen. Aber verate mir mal dann wie schnell du Daten von  gestern zwischen 14-15 Uhr auslesen kannst, und das ganze auch noch vorwärst geordnet. Genau das meinte ich. Erst sollt man überlegen.
Poste jetzt aber nich ein SQL Befehl, denn dieser formatiert ja schon!

Grüsse!

PS du formatierst ja auch 2 mal MYSQL bei der Eingabe von mir aus automatisch und dann mit SQL bei der Ausgabe. Macht keinen Sinn, ausser du willst das auch in EXEL ó.ä. bearbeiten.

Möchtest du einen Text auf deutsch ausgeben wie "Am 20 November" so formatierst du das dritte mal wo ich das erste mal ansetze!

Und noch ein Dritter Grund: Wenn einer aus Amerika postet hast du den deutschen Zeitstempel, oder denn den der Server hat. Mit einem Binären kannst du praktisch auf die Amerkianische Zeit umrechnen. Wieder ein Nachteil was MYSQL mit sich bringt!


----------



## Sicaine (16. Dezember 2004)

Öhm ja echt?

WHERE datum > '2004-11-28 14:00:00' AND datum < '2004-11-28 15:00:00'

Öhm ja so würd ich das machen. Nebenbei is das auch noch schöner als ein Timestamp


----------



## Lukasz (16. Dezember 2004)

Sag ich doch un der in Amerika hat leider die falschen Daten, und der in Japan auch. Da bringt dir die schreibweise auch nix! Soweit müssen wir auch nicht reisen. Reicht nach Greichenland schon stimmt das ding nicht mehr!
Bei einer Zeitverschiebung haben wir ein Problem .

Sag ich doch erst überlegen!

Grüsse

aber wir lassen die Disskusion lieber bleiben!


----------



## Sicaine (16. Dezember 2004)

Lukasz hat gesagt.:
			
		

> Siehst du da ist schon das Problem (du gibst es formaiter aus) und dies soll ich glauben?
> 
> Geschrieben am 2004-11-28 von ... echt?
> 
> ...




oO schön für dich dasa du da schreibst: " Am xy November" nur das mein lieber schreiben nun wirklich verdammt wenige. Schön da schreib ich mir halt mal ne kurze Funktion dazu ansonsten ist es wesentlich einfacher per SQL. nenbenbei schon mal gezählt was es für ein Aufwand ist, mit PHP aus nem Timestamp 16.12.2004 zu erhalten und mit sql? Und was übersichtlicher ist? Nebenbei darf ich da auch noch das Datum abfangen was mir bei der Foramtierung mit SQL erspart bleibt.


----------



## Sicaine (16. Dezember 2004)

Lukasz hat gesagt.:
			
		

> Sag ich doch un der in Amerika hat leider die falschen Daten, und der in Japan auch. Da bringt dir die schreibweise auch nix!
> 
> Sag ich doch erst überlegen!
> 
> ...



Hallo? Welche falschen Daten? Is doch klar dass ich das entsprechend sage Monat Jahr etc. wenn jemand suchen will. Ansonsten is das eine Formatierungstechnische Frage. Aber egal bei dir darf sich ja der Japaner mit November rumschlagen ist ja viiiiiiiiel besser -.-


----------



## Lukasz (16. Dezember 2004)

ein riesen Problem?

<?php
$morgen        = mktime(0, 0, 0, date("m")  , date("d")+1, date("Y"));
$letztermonat  = mktime(0, 0, 0, date("m")-1, date("d"),  date("Y"));
$naechstesjahr = mktime(0, 0, 0, date("m"),  date("d"),  date("Y")+1);
?> 

SELECT * FROM WHERE datum < mktime()...

Und die Funktion spar ich mir.
Sag ich doch erst überlegen...

http://de.php.net/date


----------



## TheLightning (16. Dezember 2004)

Schaut mal bitte auf

http://dev.mysql.com/doc/mysql/de/Date_and_time_functions.html

unter UNIX_TIMESTAMP()

DANN können wir weiterreden wegen umformatiertung... für PHP macht es KEINEN unterschied.... nur für MySQL und für den Query

MfG Dominik


----------



## Lukasz (16. Dezember 2004)

TheLightning hat gesagt.:
			
		

> Schaut mal bitte auf
> 
> http://dev.mysql.com/doc/mysql/de/Date_and_time_functions.html
> 
> ...



Aber genau darum geht es doch! Natürlich macht es für php was. Ohmanoman.... PHP rechnet sicher nicht mit daten wie 2004-11-28! Der SQL Befehl rechnet diesen auch erst aus. Sonst wirde ja in der DB ein Zeitstempel gespeichert, und der dann nur als 2004-11-28 angezeigt. Wer mal exportiert der weis das dem nicht so ist. Und wer nicht eis was zum Beispiel while($row=mysql.... bedeutet dem kann ich auch  nicht helfen!

Aber ich halte mich raus. Jeder wie er es will!


----------



## Sicaine (16. Dezember 2004)

@Lukas mir reichts jetzt! Zeitverschiebung? Das Problem hast du beim Timestamp genauso. Deine Argumente sind bis jetzt teilweise falsch oder einfach nicht haltbar. Informier dich erstmal was MYSql kann und schau dir mal die Seiten an was wirklich benötigt wird und du wirst feststellen, dass die Datumsformatierung mit Mysql schneller und einfacher geht. 

Und dann können wir gerne wieder weiterreden...


----------



## Lukasz (16. Dezember 2004)

es gibt nicht nur mktime() ist nur ein Baeipiel. Aber ich las dich in deinem Glauben leben!
Aber noch ein Tipp: Kauf dir das PHP Buch 

- PHP 5 & MYSQL 4 Praxisbuch  von Herrn Kannengiesser! Da steht extra ein Artikle drin warum man es nicht machen sollte!

Leider hab ich jetzt nicht vor mir sonst würde ich dir den Artikel posten. Es liegt bei mir zu Hause im Schrank!

Aber wenn dem so ist werde ich mich nachträglich darum mühen. Ich kann dir aber aus dem Gedächtniss sagen, dass es so ist. Vieleicht hat einer von euch das Buch vor sich liegen und schaut dort unter Datum und Zeitfunktionen. Glaube Seite 215 hatte es letztens erst. Dort ist da beschrieben mit Zeitverschiebung etc. und warum es so Sinn macht!

Ich denke Fehler sind menschlich aber dieses mal haben wir eben mal eine Meinungsverschiedenheit. Aber das macht nichts und kommt schon mal vor. Du selbst musst wissen wie du deine DB bestückst. Aber kommt mal wieder auf dem Boden zurück. Wäre besser ihm zu helfen!


----------



## Oliver Gringel (16. Dezember 2004)

So, jetzt muss ich mich auch mal wieder einschalten.

@Lukasz: Wer keine Ahnung hat, lieber mal die Klappe halten.
Das was du in deinen Beiträgen schreibst, ist absoluter Schwachsinn und schlichtweg falsch.

Zur Performance-Frage: Ich hab grad mal nen kleinen Benchmark gemacht, zum Vergleich von DATE und INT.

Beim Eintragen des aktuellen Datums:

```
mysql_query('INSERT INTO `date1` (`date`) VALUES ('.time().')');
mysql_query('INSERT INTO `date2` (`date`) VALUES (NOW())');
```
Das ganze in einer for-Schleife 20000 mal ausgeführt. Ergebins (die obere Zahl ist immer die INT-Tabelle, die untere die DATE-Tabelle, Angaben in Sekunden)

```
INSERT 20000

4.69330501556
4.56666183472

4.651293993
4.77843022346

4.87074017525
4.56725287437

4.56100606918
4.63716387749

5.39655685425
4.93879318237

4.25709199905
4.43373703957

4.84162306786
5.06249403954

5.07062602043
4.60275888443
```

Beide schenken sich nix. Kein wirklicher Performance-Unterschied festzustellen.


Beim Auslesen des Timestamps (100000 Einträge):

```
$q = mysql_query('SELECT `date` FROM `date1` LIMIT 100000');
$q = mysql_query('SELECT UNIX_TIMESTAMP(`date`) FROM `date2` LIMIT 100000');
```


```
QUERY 100000

1.09772515297
1.3052740097

1.15474104881
1.35974884033

1.45250487328
1.49005413055

1.27556490898
1.46494698524

1.42596292496
1.59173893929

1.2312541008
1.54599785805

1.23264503479
1.46512103081

1.35339689255
1.4985370636
```

Hier ein leichter Performance-Vorteil für INT.

Beim Auslesen eines formatieren Datums (Format: Tag.Monat.Jahr, 100000 Einträge):

```
$q = mysql_query('SELECT `date` FROM `date1` LIMIT 100000');
while($r = mysql_fetch_assoc($q))
{
	$t = date('d.m.Y', $r['date']);
}

$q = mysql_query('SELECT DATE_FORMAT(`date`, \'%d.%m.%Y\') AS `date` FROM `date2` LIMIT 100000');
while($r = mysql_fetch_assoc($q))
{
	$t = $r['date'];
}
```


```
QUERY 100000 FORMATED

1.74949097633
1.40209102631

2.13595604897
1.36897110939

2.06497788429
1.68517589569

2.04752182961
1.57983899117

1.83439803123
1.79203891754

1.82310986519
1.60400295258

2.07666921616
1.80233812332

2.05949783325
1.54520893097

1.79287195206
1.68496394157
```

Hier ein leichter Performance-Vorteil für DATE.

Alles in allem schenken sich die 2 Möglichkeiten nicht viel. Performance-Technisch ist es deswegen irrelevant, wie man die Daten speichert.


----------



## Oliver Gringel (16. Dezember 2004)

Hab den Benchmark nun nochmals auch mit DATETIME gemacht. Hier die Ergebnisse:

Eintragen: (erste Zeile INT, zweite Zeile DATE, dritte Zeile DATETIME)

```
INSERT 20000

4.69330501556
4.56666183472
4.46113204956

4.651293993
4.77843022346
5.08389806747

4.87074017525
4.56725287437
4.60454392433

4.56100606918
4.63716387749
4.47782993317

5.39655685425
4.93879318237
4.8088490963

4.25709199905
4.43373703957
4.42622494698

4.84162306786
5.06249403954
4.31641602516

5.07062602043
4.60275888443
4.62859392166
```

Beim Eintragen ist es also absolut egal.

Beim Auslesen des Timestamps:

```
QUERY 100000

1.1609120369
1.45223712921
1.39744710922

1.2569258213
1.5901350975
1.4830789566

1.07843089104
1.25645589828
1.36100506783

1.260668993
1.51001095772
1.36932897568

1.08475494385
1.37932610512
1.30494785309

1.11266613007
1.37767982483
1.3613679409

1.14749789238
1.33583307266
1.41229510307

1.10987401009
1.40876507759
1.30276894569
```

INT hat wieder leicht die Nase vorn, DATE und DATETIME schenken sich praktisch nichts.

Beim Auslesen des formatierten Datums (erste Zeile INT, zweite Zeile DATETIME, Format: d.m.Y H:i:s);

```
QUERY 10000 FORMATED DATETIME

2.21133995056
4.18734383583

2.2957470417
4.28385806084

1.99954295158
3.62903499603

2.20496416092
4.16135811806

1.89528298378
3.54531788826

1.91541194916
3.58165192604

2.05247998238
3.69539785385

1.93139791489
3.62061190605
```

In diesem Fall hat INT deutlich die Nase vorn, und braucht nur knapp halbso lang, wie DATETIME.
Noch zu erwähnen, den Datenspeicher, die die 3 Formate brauchen:
INT: 4 Byte
DATE: 3 Byte
DATETIME 8 Byte
(Angaben laut http://dev.mysql.com/doc/mysql/de/Storage_requirements.html)

Fazit: Wenn es auf Performance ankommt, und man die Beschränkung vom 1.1.1970 und ?.?.2037 hinnehmen kann, ist INT eindeutig die bessere Alternative, wenn es darum geht, mehrere Tausend Datensätze abzufragen.
Für Otto-Normalverbraucher, der keine Datenbank mit mehreren Terra-Byte Daten hat, ist der Performance-Unterschied nicht spürbar.


----------



## TheLightning (16. Dezember 2004)

Könntest du noch einen Benchmark für das auslesen von date + time.. also nicht datetime machen.. datetime verbraucht nämlich 8 byte.. date + time allerdings nur 4 byte soweit ich das noch weiß 
Könnte u.U. den Nachteil wetmachen.. btw.. hast du mit php formatiert beim auslesen? oder hast du nur die queries gebenchmarked?

Btw.: wie hast du gebenchmarked?
mit AB (Apache Benchmark)?


----------



## Gumbo (16. Dezember 2004)

Ich hab mich mal darangesetzt, einen Performance-Vergleich anzustellen, und bin auf ein etwas anderes Ergebnis gestoßen.
Überprüft hab ich einmal, wie die Spaltentypen INT, DATETIME und TIMESTAMP(14) bei Datenbankeinträgen und -ausgaben zeitlich verhielten. Ich bin von diesen Typen ausgegangen, da bei vielen Operationen oft ein bestimmter Zeitpunkt relevant ist.

Ich bin z. B. auf folgendes Resultat gekommen:
	
	
	



```
INSERT INTO INT:			1.1508231163025
INSET INTO DATETIME:			1.1804440021515
INSERT INTO TIMESTAMP(14):		1.2259771823883

SELECT von INT, formatiert:		0.071377992630005
SELECT von DATETIME, formatiert:	0.029855966567993
SELECT von TIMESTAMP(14), formatiert:	0.066927909851074
```
Demnach zu urteilen, mag das Einfügen von Werten in eine INT-Spalte schneller sein, jedoch wird das durch die höhere Formatierungszeit wieder kompensiert. Und ich denke doch, dass eine schnell formatierte Ausgabe wichtiger ist, als ein schnelles Einfügen.


----------



## Matthias Reitinger (16. Dezember 2004)

Oliver Gringel und Gumbo, danke für die (sehr interessanten) Benchmarks! Wollte ähnliches eigentlich selber durchführen, hab aber noch keine Zeit dafür gefunden. Endlich mal sachliche Argumente hier


----------



## Sicaine (16. Dezember 2004)

Hm hab selbst mal gebencht und ebenfalls festgestellt, dass bei der Ausgabe mysql schneller ist mit DATE_FORMAT!


----------



## Matthias Reitinger (16. Dezember 2004)

Sicaine hat gesagt.:
			
		

> Hm hab selbst mal gebencht und ebenfalls festgestellt, dass bei der Ausgabe mysql schneller ist mit DATE_FORMAT!


Ein Benchmark ohne genaue Ergebnisse und ohne Nennung des Verfahrens ist vollkommen wertlos


----------



## Sicaine (16. Dezember 2004)

Na eigentlich war er nur für mich intern. 

Hab versucht für beide gleiche bedinungen zu schaffen, weshalb ich auch paar mehr Benchaufrufe hab.

Schreibfehler etc. sind mir egal 
Falls es jemand nachcoden will: die benchklasse findet ihr hier: pear.php.net
Ach und zu den Ergebnissen: Teilweise kamen dann ausrutscher bei wenigen Durchgängen. 


```
<?
    require_once('./bench/Timer.php');

    mysql_connect('localhost', 'root', '');
    mysql_select_db('test');
    $timer = new Benchmark_Timer();
    $timer->start();
    echo 'start';
    $timer->setMarker('START');
    /*for($i = 0; $i < 1000; $i++){
        if(!mysql_query('INSERT INTO zeit(id, zeitint, zeitdatumlang, zeitdatumkurz, time)
                         VALUES(
                             \'\',
                             \''.time().'\',
                             \'\',
                             \'\',
                             \'\')')){
            echo mysql_error();
            die('fehler!');
        }
    }
    $timer->setMarker('Intstop');
    $timer->setMarker('Tatetime start');
    for($i = 0; $i < 1000; $i++){
        if(!mysql_query('INSERT INTO zeit(zeitdatumlang) VALUES(NOW())')){
            echo mysql_error();
            die('fehler!');
        }
    }
    $timer->setMarker('Datetime stop');   */


  for($i = 0; $i < 10; $i++){
        if(! $id = mysql_query('SELECT zeitint FROM zeit LIMIT 0,1000')){
            echo mysql_error();
            die('fehler!');
        }
        while($row = mysql_fetch_assoc($id)){
            $zeit = date('d.m.Y', $id['zeitint']);
            //echo $zeit.'  ';
        }
    }
    $timer->setMarker('Intstop');
    echo '<br>';
    $timer->setMarker('Tatetime start');
    for($i = 0; $i < 10; $i++){
        if(! $id = mysql_query('SELECT DATE_FORMAT(zeitdatumlang,\'%d.%m.%Y\') AS zeit FROM zeit LIMIT 1000,1000')){
            echo mysql_error();
            die('fehler!');
        }
        while($row = mysql_fetch_assoc($id)){
            $zeit = $row['zeit'];
           // echo $zeit.'  ';
        }
    }
    $timer->setMarker('Datetime stop');


    $timer->setMarker('STOP');

    echo 'stop';
    $timer->stop();
    $timer->display();
?>
```


----------



## JohannesR (17. Dezember 2004)

Sicaine hat gesagt.:
			
		

> Öhm ja sicher alles klar...
> Wir ignroieren bitte einfach die oben verfügbaren Möglichkeiten mit Mysql ein Datum zu formatieren @ JOhannes röttinger



Genau das meine ich, einfach wild rumflamen, dumme Dinge quatschen, das Maul aufreissen, eine kranke Rechtschreibung an den Tag legen und meinen Namen verballhornen... Ich will ganz offen sein, haettest du gelesen, was ich geschrieben hab, muesstest du dich nicht mit dem Dreck oberhalb ueberall blamieren. Ich schrieb, aussageaehnlich, dass ein Unix-Timestamp fuer wilde Aktionen in PHP besser geeignet, einfach, weil man damit (in PHP) mathematische Dinge tun kann. Zieh mal 60 von einem einfach gefetchten DATETIME ab (in PHP). Mit einem Unix-Timestamp geht das! Ich werde versuchen meine Aussage, noch kuerzer zu fassen, so dass sie verstaendlicher ist (rede ich so ein kompliziertes Zeug? Ich denke doch nicht, oder?): Ein Unix-Timestamp ist unter PHP in 99% aller Faelle praktischer! Ich hab doch kein Wort davon gesagt, dass MySQL nicht in der Lage waere, ein Datum zu formatieren?
Echt, ich raff es nicht, wie dreist man einfach eine Aussage unterstellen kann...
Ich denke, ihr solltet einfach ueber euren Tellerrand gucken, und testen, welche Methode fuer euren Zweck besser geeignet ist, bzw. womit ihr besser klar kommt; mit den PHP- oder den MySQL-Zeitfunktionen (seien sie nun fuer einen UNIX-Timestamp oder ein Date(time)-Feld).


----------



## Sicaine (17. Dezember 2004)

> und damit in PHP wilde Dinge anstellen will (Wochentag rausfinden, Kalenderwoche, etc. pp.) ist ein Timestamp einfach viel komfortabeler. *kopfschuettel* So schwer ist das doch nicht, oder


Ich bezog mich auf das hier mein lieber Johannes Röttger. Hier ist halt nunmal ein Timestamp als int nicht kompfortabler... 

Lies du erstmal deine Beiträge richtig.
Und nein ein Timestamp ist zu 99% nicht kompfortabler. Meistens wird das Datum formatiert ausgegeben was in MySql schneller und einfacher geht und nicht damit gerechnet. Aber das wilst du ja anscheined nicht verstehen.

Edit: (hab jetzt noch bisl zeit )
Und nächstes mal lies deine Beiträge mal genauer durch bervor du andere blöd anmachst und rumflamest. Und nur weil ich deinen Namen jetzt nicht fehlerfrei geschrieben habe, brauchst auch nich gleich in die Luft zu gehen...(Wenn ich schnell schreibe, dann soll ich mir deinen Namen merken? Vielleicht am besten noch extra markieren und dann einfügen? Weils ja sooo wichtig is, dass der Nick( oder name) richtig geschrieben ist. Es gibt wichtigeres z.b. seine eigene Beiträge richtig schreiben.

Edit 2: Ich werf jetzt nochmal was in den Raum was anscheined untergegangen ist und wovon ich auch ausgehe:


> Dann will ich nochmal ein weiteres Argument in den Raum werfen:
> Eine Datenbank soll Daten in strukturierter Form speichern.
> Dabei spielt es keine Rolle, mit welcher Programmiersprache oder Anwendungssoftware ich auf diese Daten zugreife


Nur weil ich nen Int auch in nem Varchar speichern kann, tu ichs nicht. Wenn ich einen Wert von 0-255 speichern will, nehm ich auch keinen Int her nur weils geht sondern nen TinyInt und ich nehme auch keinen Text für nen Namen etc. Die Leute ham sich scho was überlegt, warum sie die Datentypen Timestamp und Date und Datetime eingefügt haben. Das zeug existiert ned umsonst. Parallel dazu was glaubst du kapiert jemand schneller? Wenn da jemand Datetime oder Timestamp verwendet oder int? Ich würd und werde weiterhin davon ausgehen, dass jemand Datetime für die Zeit standardmässig benützt.


----------



## JohannesR (17. Dezember 2004)

Sicaine hat gesagt.:
			
		

> Ich bezog mich auf das hier mein lieber Johannes Röttger. Hier ist halt nunmal ein Timestamp als int nicht kompfortabler...


Nein, du liest immernoch nicht richtig... ARGS! Siehst du die beiden Worte "*in PHP*"? Siehst du sie?




> Lies du erstmal deine Beiträge richtig.
> Und nein ein Timestamp ist zu 99% nicht kompfortabler. Meistens wird das Datum formatiert ausgegeben was in MySql schneller und einfacher geht und nicht damit gerechnet. Aber das wilst du ja anscheined nicht verstehen.


Darauf kommt es doch garnicht an Ich habe eine Aussage gemacht, und zwar, dass man mit einem Int leichter rechnen kann. Das kannst du nicht damit wiederlegen, dass du nicht mit einem Int rechnen willst! Geht das in deinen Kopf? Ja oder Nein?



> Edit: (hab jetzt noch bisl zeit )
> Und nächstes mal lies deine Beiträge mal genauer durch bervor du andere blöd anmachst und rumflamest. Und nur weil ich deinen Namen jetzt nicht fehlerfrei geschrieben habe, brauchst auch nich gleich in die Luft zu gehen...(Wenn ich schnell schreibe, dann soll ich mir deinen Namen merken? Vielleicht am besten noch extra markieren und dann einfügen? Weils ja sooo wichtig is, dass der Nick( oder name) richtig geschrieben ist. Es gibt wichtigeres z.b. seine eigene Beiträge richtig schreiben.


Tja, wenn ich dich Sick-aine nenne, findest du das sicher auch nicht lustig... Und das ist nur dein Nickname. Es ist ganz einfach, ich lege Wert darauf, dass mein Name richtig geschrieben ist. Wenn dir das nicht passt, dann schreib ihn nicht, ansonsten wunder dich nicht, wenn ich dich anmache!



> Nur weil ich nen Int auch in nem Varchar speichern kann, tu ichs nicht. Wenn ich einen Wert von 0-255 speichern will, nehm ich auch keinen Int her nur weils geht sondern nen TinyInt und ich nehme auch keinen Text für nen Namen etc. Die Leute ham sich scho was überlegt, warum sie die Datentypen Timestamp und Date und Datetime eingefügt haben. Das zeug existiert ned umsonst. Parallel dazu was glaubst du kapiert jemand schneller? Wenn da jemand Datetime oder Timestamp verwendet oder int? Ich würd und werde weiterhin davon ausgehen, dass jemand Datetime für die Zeit standardmässig benützt.


Ich glaube kapiert hat hier jeder den Unix-Timestamp... 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... Klar, du kannst auch ein Datetime in der Datenbank speichern und es dann als Timestamp zurueckgeben, was besser ist ist aber immer fallabhaengig. Vor allem, nachdem die Benchmarks gezeigt haben, dass INT schneller ist als Datetime, und damit natuerlich viel schneller als Datetime mit umrechnung zum Unix-Timestamp.


----------



## Sicaine (17. Dezember 2004)

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.

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

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.


----------



## TheLightning (17. Dezember 2004)

@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 (17. Dezember 2004)

Sicaine hat gesagt.:
			
		

> 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 (17. Dezember 2004)

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 (17. Dezember 2004)

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 (17. Dezember 2004)

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 (17. Dezember 2004)

TheLightning hat gesagt.:
			
		

> 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 (17. Dezember 2004)

Johannes Röttger hat gesagt.:
			
		

> 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 (17. Dezember 2004)

Gumbo hat gesagt.:
			
		

> 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 (17. Dezember 2004)

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 (17. Dezember 2004)

Matthias Reitinger hat gesagt.:
			
		

> 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)


----------



## Sicaine (17. Dezember 2004)

Hm die Umwandlung verlangsamt den Datetime zu nem int bzw. timestamp um 3%! 
Und vergesst dabei aber nicht, dass das eine ein 64bit int(geh mal davon aus nach M.R.ers "quote" und das andre nur ein 32bit int is. Dafür sind die 3% sehr gut. Aber ich will ein Projekt sehen, wo man proentual gesehen öffter damit rechnet als es auszugeben! Wenn ich mir hier so dieses Forum angucke, da seh ich verdammt viele formatierte Datume(oO was isn da die Mehrzahl?) Weshalb ich weiterhin jedem Datetime ans herz legen werde und selst benützen werde, wobei ich mir das vielleicht bei meinem Browsergame überlegen müsste wobei hier trozdem dann ein Timestamp benützt werden würde.


----------



## Oliver Gringel (17. Dezember 2004)

Benchmarks hin oder her, aber im Alltagsbetrieb wird man nie einen Geschwindigkeitsunterschied feststellen können. Wer nutzt denn PHP und mySQL für irgendwleche Datumsberechungen / -ausgaben bei mehreren Tausend Datensätzen pro Query bzw. extrem vielen Querys pro Sekunde?
Sobald man neben dem Datum noch andere Werte mit ausliest (was ja meistens der Fall seien sollte), ist kein Geschwingkeitsunterschied mehr feststellbar.

Deshalb denke ich, wer seine Datumsangaben als Unixtimestamp und Int speichern will, der soll das tun. Wer aber die mySQL-Datumsfunktionen nutzen will, und auch mit Daten vor dem 1.1.1970 arbeiten will (und das kommt ja durchaus mal vor), der soll sich für DATE / DATETIME / TIMESTAMP entscheiden.


----------



## TheLightning (17. Dezember 2004)

Och ... bei nem richtig großen CMS kann das schon mal vorkommen daß so ein Fall eintritt...


----------



## Oliver Gringel (17. Dezember 2004)

TheLightning hat gesagt.:
			
		

> Och ... bei nem richtig großen CMS kann das schon mal vorkommen daß so ein Fall eintritt...


Nicht mal bei Seiten, wie eBay wird sowas ins Gewicht fallen


----------



## TheLightning (17. Dezember 2004)

Oh doch... und das ist der Grund warum die kein MySQL sondern eine kommerzielle Lösung wie Sybase oder Oracle verwenden..
Da laufen auch keine 0815-Linuxkisten im Hintergrund sondern UNIX-Großrechner (Standard wäre Sun-Kiste mit Solaris und Oracle-DB)


----------



## Sicaine (17. Dezember 2004)

Hm ich denke schon dass es was bringt, wenn man nen Query optimiert, der paar hunderttausend x am Tag aufgerufen wird. Vielleicht nicht viel vielleicht auch ned wirklich viel aber ein kleines bischen vielleicht öhm 100 oder 1000 Anfragen mehr? Na gut wird wohl spekulation sein.

Btw: Wenn jetzt noch der Artikel kommt den Lukaz posten wollte hm.


----------



## Oliver Gringel (17. Dezember 2004)

TheLightning hat gesagt.:
			
		

> Oh doch... und das ist der Grund warum die kein MySQL sondern eine kommerzielle Lösung wie Sybase oder Oracle verwenden..
> Da laufen auch keine 0815-Linuxkisten im Hintergrund sondern UNIX-Großrechner (Standard wäre Sun-Kiste mit Solaris und Oracle-DB)


Das ist ja wieder was ganz was anderes. Das mySQL solchen Aufgaben nicht mehr gewachsen ist, das ist klar. Aber mit Sicherheit nicht wegen der Performance einer Datums-Umformatierung.
Wie in meinen Benchmarks zu sehen, ist der Unterschied, einen INT auszulesen, und einen DATETIME mit UNIX_TIMESTAMP auszulesen, nicht besonders groß. Meine Abfragen bezogen sich aber auf Tabellen, in denen nur dieser Datumswert gespeichert ist. Bekommt die Tabelle nun noch mehr Spalten, die auch alle abgefragt werden, wird der prozentuale Geschwindigkeitsunterschied zwischen INT und DATETIME noch um viele Größenordnungen geringer.
Da macht es wahrscheinlich mehr aus, ob ich einen Usernamen als VARCHAR(20) oder VARCHAR(18) abspeichere.


----------



## Matthias Reitinger (17. Dezember 2004)

hpvw hat gesagt.:
			
		

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


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


----------



## TheLightning (17. Dezember 2004)

Oliver Gringel hat gesagt.:
			
		

> Das ist ja wieder was ganz was anderes. Das mySQL solchen Aufgaben nicht mehr gewachsen ist, das ist klar. Aber mit Sicherheit nicht wegen der Performance einer Datums-Umformatierung.
> Wie in meinen Benchmarks zu sehen, ist der Unterschied, einen INT auszulesen, und einen DATETIME mit UNIX_TIMESTAMP auszulesen, nicht besonders groß. Meine Abfragen bezogen sich aber auf Tabellen, in denen nur dieser Datumswert gespeichert ist. Bekommt die Tabelle nun noch mehr Spalten, die auch alle abgefragt werden, wird der prozentuale Geschwindigkeitsunterschied zwischen INT und DATETIME noch um viele Größenordnungen geringer.
> Da macht es wahrscheinlich mehr aus, ob ich einen Usernamen als VARCHAR(20) oder VARCHAR(18) abspeichere.



Ich habe die ganze Zeit an SELECTS die über den DATETIME aggieren gedacht.. wenn du dann noch joins drin hast kann das bisschen was für timestamp verantwortlich in summe dann doch schon etwas an einbusen mit sich bringen...


----------



## Gumbo (17. Dezember 2004)

> Bekommt die Tabelle nun noch mehr Spalten, die auch alle abgefragt werden, wird der prozentuale Geschwindigkeitsunterschied zwischen INT und DATETIME noch um viele Größenordnungen geringer.


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.


----------



## Oliver Gringel (17. Dezember 2004)

Gumbo hat gesagt.:
			
		

> 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 (17. Dezember 2004)

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 (17. Dezember 2004)

Lukasz hat gesagt.:
			
		

> 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.
> 
> ...



Ö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 (17. Dezember 2004)

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 (17. Dezember 2004)

Matthias Reitinger hat gesagt.:
			
		

> 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 (17. Dezember 2004)

OK ich denke das kann man so stehen lassen


----------



## Sicaine (17. Dezember 2004)

@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 (17. Dezember 2004)

hpvw hat gesagt.:
			
		

> 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.


----------

