nicht angemeldet
Moin!
»» Du verwendest den von der DB angebotenen Datentypen für Zeitpunkte, und wandelst, sofern der Bedarf besteht, im SELECT in die passende Ausgabeform, bzw. rückwärts beim Schreibzugriff aus dieser Form. In der Regel haben Datenbanken für beide Richtungen Transformationsfunktionen.
Naja, wie ich grad auch dedlfix schrieb: mit CURRENT_TIMESTAMP als Default bekomme ich einen Eintrag my_cts in der Form "2009-03-09 12:38:30", durch DATE(my_cts) und TIME(my_cts) erhalte ich dann eben 2009-03-09 bzw 12:38:30, aber ich finde keine Funktion, die mir die Sekunden ab 1.1.1970 ausgibt, wie ich sie für PHPs date() brauchen würde.
SQLite kennt keinen expliziten Datumstypen. http://www.sqlite.org/datatype3.html SQLite kennt grundsätzlich keine strenge Typisierung von Spalten. Man kann offensichtlich auch Text in Integer-Spalten speichern, ohne dass das zu Zerwürfnissen führen würde, weil SQLite den Datentyp nicht mit der Spalte speichert, sondern mit der einzelnen Zelle.
Dementsprechend schwach ist SQLite auch hinsichtlich der Datumsfunktionen, verglichen z.B. mit MySQL.
Daraus könnte man jetzt folgern, dass die Verwendung von Datumsfunktionen in SQLite eigentlich eher Sache des aufrufenden Programms sein sollte. Dem würde ich allerdings nicht unbedingt zustimmen. strftime() liefert beliebig schön formatierbare Datumsstrings, und die DB versteht insgesamt 12 verschiedene Datumsformate, so dass eigentlich keine Notwendigkeit besteht, dass die Applikation ihrerseits eine Umrechung in UNIX-Timestamps vornimmt.
Wenn die Unix-Timestamps allerdings unumgänglich sind (was in meinen Augen eher eine schlechte Designentscheidung wäre - Datumsbehandlung würde ich immer möglichst komplett in die DB auslagern, und die Werte in der Applikation nur in alle Richtungen "durchreichen"), dann wird SQLite diese Werte ohnehin als Integer speichern.
- Sven Rautenberg