nicht angemeldet
Ahoi Vinzenz,
»» Da aber üblicherweise in DB-Abfragen doch wieder Zeitkomponenten reinkommen, die man eventuell nicht vorberechnen kann, besteht die Tendenz, Zeitberechnung AUCH in der DB zu machen. Dann aber sollte man sie AUSSCHLIESSLICH in der DB machen, nicht mehr in PHP.
... und dann wären wir an einem Punkt der Ausgangsfragestellung angelangt:
dies wäre ein Grund, SQLite nicht zu benutzen, so wie es auch im Handbuch steht:<zitat>
"In order to achieve simplicity, SQLite has had to sacrifice other
characteristics that some people find useful, such as high concurrency,
fine-grained access control, a rich set of built-in functions, stored
procedures, esoteric SQL language features, XML and/or Java extensions,
tera- or peta-byte scalability, and so forth. If you need some of these
features and do not mind the added complexity that they bring, then
SQLite is probably not the database for you.
[...]
Another way to look at SQLite is this: SQLite is not designed to replace
Oracle. It is designed to replace fopen()."
</zitat>
Ja. In dem Fall entscheide ich mich vermutlich dafür, die wenn überhaupt nötige Logik bei PHP zu belassen, und zB. einen Zeitstempel mit PHPs time() zu erstellen, wobei ich mittlerweile sogar zweifle, ob das Erstellungsdatum für mich Relevanz hat. Simples Fazit: für reines Speichern und Basic SQL taugt das ganze, ist dann zB. auch mit Zend_DB "kompatibel", bzw. dort aus dem Quickstartbeispiel vom Zend-Framework ja auch entnommen, als Vorbild.
Dank und Gruß,