It’s a law of programming that early optimization is a very bad idea. Why fill your kitchen with gadgets when you don’t know how to cook?
On the other hand, what if I’m using an oxy-acetylene torch to cut onions? Shouldn’t I go to the market to see if knives are for sale?
So I’ve looked into replacing sqlite with MySQL. Maybe it’s faster, maybe it’s better; all the web programming books teach PHP and MSQL forchrissakes, and I’m using neither. So today I tried downloading MySQL and learned a couple things:
1. Wow, was that installation hard work. This means ANOTHER interplanetary programming detour and I’m sick of detours. I want to get to work.
2. MySQL’s python for windows implementation REALLY sucks.
Discouraged, I thought I’d read around a bit. At stackoverflow I found a great post that lead to an even better podcast with the inventor of Sqlite.
The upshot appears to be this: if you don’t need lots of simultaneous WRITING to your database, sqlite is probably better. Another heuristic: if your website fits on one computer (!?), sqlite is probably better. Yet another: if you get fewer than 100,000 hits a day (!!!) sqlite is the winner.
The big downside to sqlite is that it only allows one user to write data into it at one time: the database “locks”. The big upside? Just about everything else, I think.
Anyway, that little bit of research makes this whole question absolutely ridiculous for my purposes, so I’m sticking with sqlite.
Not Unreasonable 