Moin!
»» 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.
Auf der anderen Seite sind SQL-Abfragen, die dynamisch mit Funktionsergebnissen rechnen, wie sie naturgemäß von Funktionen wie NOW() zurückgegeben werden, immer ein Kandidat für schlechtere Performance, weil aufgrund des dynamischen Funktionsergebnisses der Query-Cache vermutlich nicht genutzt werden kann. Abfragen mit konkret statischem Datum, selbst wenn es vom abfragenden Skript nur dynamisch vorberechnet ist, aber dann statisch im Query landet, lassen sich, sofern die betreffenden Tabellen nicht verändert werden, aus dem Cache bedienen, was erheblich die Performance steigert.
Diese Überlegungen treffen aber natürlich nur zu, wenn man wirklich ein DB-Performanceproblem hat. Wenn man vor der Wahl steht, irgendein Eigengebräu als Speicher zu verwenden, oder eine Datenbank, dann steht man vermutlich noch nicht vor einer Performancefrage.
... 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>
Wenn ich die Wahl hätte, ein Eigengewächs mit fopen() zu nutzen, oder SQLite, dann fiele meine Wahl vermutlich oftmals auf SQLite.
Bestünde die Wahl zwischen SQLite und MySQL, wählte ich vermutlich MySQL.
:)
- Sven Rautenberg