I got a call from my wife this morning telling me that one of my old web-development clients had called to say they were getting an error message when trying to update part of their website. Since the function in question has been working perfectly for the better part of three years...the likely problem was obvious, particularly since this feature should have roughly one entry per week, right?
I logged in to their content-management system*, reproduced the error, opened up the mySQL database, saw that yep, there were 127 entries, changed the id field of the table from a TINYINT (8-bit) to a SMALLINT (16-bit), went back to content-management, and made sure the error was gone. Total time, 2 minutes. Except that it wasn't 2 minutes. It took 20.
Why? Because I had to search back through several years of email to find the login and password for the database. Why not just read that straight from the code? Because it would have taken even longer to find the FTP login info (buried on a laptop with a malfunctioning screen that I have with me and on a new laptop that's sitting at home right now).
So, morals of the story:
1. Unless you really have a storage issue, don't use really small field sizes even where it makes sense (e.g., there are tables in the database that have less than 10 rows, and the user has no way to add more)...because you might get in the habit and use them where it doesn't.
2. Put some real planning into where you keep old client info. Is it truly backed-up? Will you be able to get your hands on it quickly from almost anywhere?
*Am I the only one bothered by the fact that basically no client is ever bothered that I retain access to their database, webpage code, and content-management system (any one of which would allow me to do some serious damage). I've tried to tell clients how to go about changing passwords and database settings when I turned over the finished product, but once I tell them that they'll have to let me back in if they need a bug fix, they always just want to leave things as they are. Which I suppose is fine, but if there's enough staff turnover, in a few years it's possible that no one at the client will know I still have such access.
In general, I think this shows a blindspot many people have about computer security. If you ask someone at a bank, say, who has the most "trusted" person (data-security-wise) is, they're likely to say the CEO or President or some such. Of course, it's actually the database administrator or whoever sets up accounts, but he/she's just a peon and doesn't count.
Good stuff Bro. Funny thing is I go in the complete opposite direction. I always used int(10) for all my id fields. And yes I know adding to the table every minute would take a few millennia to fill it up. Still you never know how much people might use their website and its good to be prepared just in case. ;)
ReplyDeleteAnd its not just you on website logins. I always thought that as well.
I think my problems are a leftover from having learned a bit of programming back in the Dark Ages, then jumped forward into the modern, memory-is-rarely-an-issue world without making the transition gradually over the years.
ReplyDeleteAnd the truth is that I first just switched to 32-bit ints just to the problem right away and only later went back and decided that 16 bits would be enough. (These are weekly events, so 630 years worth seems sufficient.)
I honestly think part of the problem is database systems' insistence on using somewhat non-standard names for field types. If it'd been BYTE instead of TINYINT, I'd have been a bit less likely to screw it up....
Hi! This is kind of off topic but I need some advice from an
ReplyDeleteestablished blog. Is it hard to set up your own blog? I'm not very techincal but I can figure things out pretty quick. I'm thinking about creating my
own but I'm not sure where to begin. Do you have any ideas or suggestions? With thanks
Also visit my web page want to lose weight fast