Bob Browning's blog

The sales manager came down to the IT department and looked around. He spotted a young developer who looked a bit bored.  His name plate said ‘Luke’. “I have a small job for you if you are interested”. Luke  nodded. “We get sales orders from out customers. The warehouse handles them but we can’t get access to the data. Can you write a little program to store then on a computer for me.”  Luke looked at a file of sample orders. “Sure no problem.”

He turned to the jaded old database administrator (Joda) in the corner “This is a great application for a NOSQL Document database like MongoDB or CouchDB.”  Joda looked up – “That is a decision, regret you will”.  Luke muttered something about ‘luddite’ and went back to his desk and coded up one NOSQL document per sales order, with customer details and an embedded array of order lines. The logical way to solve the problem.

The sales team hired a clerk to enter the orders every morning. They were delighted. A month later the sales manager came back down. “Luke, can you do me an analysis of sales per product per month.” This was not problem  and Luke soon had it coded up. A couple of months later another visit. “Luke, can you do me query so that I can enter a product and get a list of sales per customer so we can see who the big buyers are.”

After a succession of similar requirements, it dawned on Luke that the important data here were the order lines, which he had buried away in the invoice documents.  Luke turned to Joda: “Every time the users come up with a query, I have to deconstruct the invoice document. I have some up against Rule 2:Needing to access an object on its own is a compelling reason not to embed it.  But I didn’t know this was going to happen.”  He paused “Don’t say it – if I had normalized the data  I would have a table of invoice lines that I could slice and dice.”

Joda smiled. “Two lessons you have learned young Luke. An SQL database is designed around the underlying data. A NOSQL database tends to be designed around the application. And applications change.  So think twice about denormalizing when the requirement is vague.”

Luke nodded – fair enough. But what is the second lesson.  Joda: “It always makes sense to use the same technology as everyone else in the department.  Oh by the way enjoy your holiday”.

A couple of weeks later a tanned Luke returned to work and got sent straight away to the boss’s office.  He didn’t look happy. “Luke – that system you wrote broke down while you were away. Nobody else knew what to do, so I had to get a couple of consultants in at an exorbitant cost. They were not flattering about the quality of the code.” Luke shuffled. “The end user kept adding new requirements.”  

The explanation didn’t go down well. He was sent back to rewrite the application using the same SQL database as the rest of the department. Second lesson learned.