What I Learned Today (SQLITE vs MySQL)

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s