T'was a dark and stormy night..
It was a dark and stormy night by =aki-no-mia on deviantART
[/kidding]
Anyway, several months before I started in my current job, I got this project to expand an HR tracking software from a local startup. It was a fairly simple project and the company already has a small internal development team that is doing another part of the system (the Point-of-Sale, if I'm not mistaken). Not only that, but an ISO 9001 Audit was ongoing in the other departments of the company- with people rifling through databases and checking that everything has a trail (eg. properly documented).
One of the Database Tables had a column named "ID", which is the table's primary key. The data was formatted like so: 20100123, 20100202, etc. Obviously, it was in a YYYYMMDD date format, so this is what the auditor did:
1.) Change the key of one record from 20100129 to 20090101, which is a valid key
2.) Open the 2010 monthly reports.
And lo and behold, the record disappeared from the reports. It turned out that one of their developers was using the ID of the records to filter the reports:
If CDbl(Record.ID) >= 100000 Then Report.Add(Record)I don't know if it was brilliance or plain stupidity. I guess it does work. IDs are supposed to IDentify specific records, and not keep track of dates- its data formatting does not, should NOT matter.
As a workaround, the Senior Dev (who was pissed and almost fired the dev responsible) instructed us to use the following date format: YYMDD - Two digits for the year, One AlphaNum for the month, and two digits for the day. The month AlphaNum works like so: 1 through 9 for January to September, X for October, Y for November and Z for December.
Now THAT is brilliance: It shortened the ID from 8 digits to just 5 and prevented devs from converting the IDs to numbers and using them mathematically :D
Until next time, Sayonara~
