Database administrators tend to be pretty conservative about how databases are altered. This is for good reason- that data is mission critical, it's availability is vital, and any change you make threatens that stability and reliability. This conservatism ranges from "we have well defined processes for making changes" all the way to "developers are dangerous toddlers playing with guns and we can't allow them to do anything lest it break our precious database."

"Grumpy" Gus worked with some DBAs that fell much more on the "developers can't be trusted" end of the spectrum. This meant they had big piles of rigorous processes to make sure only the most important, definitely required changes to the database ever got made. The process involved filing several documents, marking an entry on a spreadsheet, emailing a [email protected] inbox, and then waiting. Your request would snake its way through a Database Management Subcommittee, then get kicked over to a Business Need Evaluation Working Group. If the working group agreed that this change met a level of business need, it went back to the subcommittee, which reviewed the findings and if they agreed escalated it to the monthly Database Administration Steering Committee and Database Users Group meeting. Once again, it would get reviewed. If accepted, the DBAs could write a change script, and apply it in the next database maintenance window.

From start to end, the process took a month, if not longer, and your request could be kicked back at any step in the process. If you didn't fill out the initial documents in the correct order, and to the satisfaction of the groups, down to using, commas, correctly, it could be rejected. You may or may not be told why.

All this created a problem: the "big boss" wanted three new boolean fields in the database, and wanted it yesterday. There was no guarantee that the committees would even let Gus finish the process. And it was impossible to get it done in any sort of timely fashion.

But Gus was smart, creative, and aware that the FAX_PHONE_NUMBER field on all of their customer records were blank. Gus couldn't change the schema, but he could change the way his application used the database fields.

UPDATE CUSTOMER_TABLE SET FAX_PHONE_NUMBER = CAST (HAS_DOCK * 64 + HAS_LOCK * 32 + HAS_DOORBELL * 16 as varchar(10));

Problem "solved".

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!