July, 8, 2004 archives
getting the right abstraction from your database abstraction layer
jeremy zawodny rails against database abstraction layers, particularly those that aim to provide database independence. the abstraction layer that i use is really just aimed at making it so i can do more with less code. it’s inspired a bit by the PEAR DB layer, but without the database independence cruft. it means i can write $db->get_assoc("SELECT foo, bar FROM users WHERE id = ?", $id)
instead of having the same four lines of query building and row fetching all over the place.
this is actually the object-oriented version of the procedural version of this that i used to use. i needed to be able to use it in situations where i may have multiple connections to different databases open, so the old abstraction layer got painted with a thin OO veneer. the mysql extension’s handling of a default connection is useful for the lazy programmer, but doesn’t mix well with functions that take a variable number of arguments.
vegas, baby!
so i bit the bullet and made plans to go to vegas next week for home entertainment 2004. unfortunately, i made the decision too late to actually register for the show beforehand, so i’ll have to try my luck at on-site registration. i need to pick up some perforated business cards so i can gin up some official-looking business cards and hopefully avoid the registrations from the public will be denied
issue.
i’ll be staying at the new frontier, which had the important qualities of being cheap and relatively close to the venetian, where the show is being held.
this seriously ups the amount of money i’ve committed to this zany backup career plan. then again, it’s still way less than i’ve spent on the server and hosting for blo.gs and this site.
actually, i suppose “way less” may depend on how any gambling goes.
and i guess why i’m even considering a backup career plan is worth some explaining at some point. maybe later.