Size isn't the problem with SQLite databases. It's that it's unbearably slow with even fairly trivial joins and most of the other operations where it'd make sense to actually have an SQL database. SQLite is fine for tabular data, but then, so are a bazillion other things. Basically it's the perfect SQL database for the times that you shouldn't be using an SQL database.
I don't quite agree with that. One advantage I see for using SQLite is that you CAN use it as an SQL database for administrative purposes: You can quickly import/export the data from or into another SQL database, you can quickly generate an ad hoc report, etc.
So to me, the SQLite use case is often where the PRIMARY purpose of a database could be served nearly as well with fopen(), but where it's likely that there will be SECONDARY uses for which having a convenient universal access method would be useful.
I've even considered writing an external table plugin for SQLite to facilitate diagnostics and reporting of a complex ad-hoc file format I designed so I could get those benefits with a custom data structure; unfortunately, doing that seems somewhat complex in SQLite.
> Basically it's the perfect SQL database for the times that you shouldn't be using an SQL database.
Well, that comment resonates with me. I feel the same but can't support it well with arguments. Care to share what you would use instead? F.ex. to replace fopen() with like the OP describes.
