Include, include. My kingdom for an include

It’s been a while since I’ve had a work-related rant, so here’s one to help bolster the stats. We recently got a copy of a PHP website which needed to be re-developed. The website is, as with most sites these days, database driven. Although I use the word database loosely, since they use MySQL as opposed to a decent RDBMS like PostgreSQL. However, flame-wars aside, this web site was using MySQL as their database of choice.

As with all databases (even the toy ones like Mysql - kidding) a login is required. To do a successful login you need to know the server on which the database lives, the user which can access the database and the password for that user. Now, since this information is the same for every page in the site which requires access to the database it makes sense to have this defined in a single place in the code, then all other pages to use this definition. This also has the added advantage that if the server, username or password ever change (and yes kids, passwords should be changed frequently) then only 1 file needs to be updated.

That would be the sensible way of doing it. But did they do this? Did they buggery. At the top of every PHP file they have the server, username and password coded. Every single document. That’s 63 fricking pages that need changed every time the password changes. 63 files need updating when copying files from a test environment to a live environment. 63 bloody files!! Have I made my point yet? This is one of the most fundamental things when using databases in any application. It really rather irks me.

However, on a plus note, I got my first payslip in over a year today. Not that I get paid for another week and a bit, but a payslip is good. Contracting has its advantages, but there’s a lot to be said for a regular income. Means I can buy beer regularly for a start… mmmm … beer