I have a real production reason to use DBD::SQLite - storing page hits for a large CGI application. One application I used to work on had a MySQL front-end database (used for session info and page-hit stuff) and an Oracle back-end database for actual data. There was a table that recorded every hit this application received. That table took over 45 seconds to return any sort of useful information. (It was extremely useful in debugging issues that occurred when users did stupid things.)
in reply to Would you use SQLite?
Now, one thing I would've loved to have would be the information stored per week or per month, but making the table structure necessary would've been ... annoying ... to say the least. But, a simple module overlay on DBD::SQLite would've helped immensely. Just have a dbfile for each week and ATTACH it as necessary. From what I can see, it would've easily handled the session information, as well. (Though, again, we could've used a separate file for each session and ATTACHed as necessary ... ? I think this would've been better because there were four front-end servers in a round-robin setup ...)
We are the carpenters and bricklayers of the Information Age.
The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6
... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.