Friday, December 7, 2007

Super Global Variables

I've been working on a program to manage my budget for the last few months and when I first started out I had it store all of the data in XML files which were loaded into well organized classes. It was pretty simple to get up and running and was working really well until I started to want to "link" some of the values together (transactions to budget categories) and do some statistical analysis type of things. I definitely could have added support for storing these links and doing these types of "queries" in my classes, but it just seemed like reinventing the wheel because databases could do exactly what I wanted and more.

So I decided to start playing around with using a database. SQLite was amazingly simple to get up and running, and despite a few complaints (no foreign key support and limited ALTER TABLE support which fortunately have solutions (foreign keys through triggers and work around for removing columns)) it got the job done with less hassle than I expected. I definitely had to brush up on my SQL since I hadn't written a line of it in years, but for the most part it's a pretty simple language and I was linking and querying the data in no time.

But this whole thing got me wondering, "this ease of use has to have an explanation and most likely an associated drawback or cost". After thinking about this for a while, I came to the conclusion that databases are basically just "Super Global Variables". They're "global" because they're a nebulous set of data that's accessible from any part of a program, and they're "super"
because you can grab them in various forms/combinations. When I first realized this, I kind of chuckled to myself, because programmers always talk about how global variables (just a super set of static variables) are evil/problematic but they'll use a database without even thinking about it. It just made me realize how sometimes our own abstractions actually hide us from the ugly truth that we'd probably rather ignore.

No comments: