Datum?

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
3. für was willst du unbedingt den UNIX-Timestamp als Integer speichern.. dadurch muss dein Interpreter nur mehr rechnen => Performancegedanken

MfG Dominik

Guten Morgen schau mal einen Post über deinem !
:mad:
 
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 ;)


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

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.
 
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.
 
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?
 
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?
 
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.
 
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
 
Zurück