Andy Yun (@sqlbek) invites us to write about preconceived notions.
There are plenty that I see and challenge, but I’m going to describe how I changed my thinking about databases back in the 90s.
At university I studied Computer Science, which felt like it was mostly about algorithms and paradigms. It covered how to approach particular kinds of problems, what languages suited what problems and why, and how to model things. The answer to a lot of things was “C’, whether it was a multiple choice question, or the question about which language would be used to solve something.
I skipped the database subject. Everyone said it was overly basic, easy marks, and not particularly interesting. I wasn’t interested in it. Not when there were subjects like Machine Learning where we’d implement genetic algorithms in LISP to find ways to battle other algorithms in solving the prisoner’s dilemma. Or the subject where we’d create creatures (in software) that would follow each other in a flocking motion around a cityscape. Everything I heard about databases was that they were largely of no importance.
I landed a job with about five months in my degree remaining. I was due to start just after New Year. A weekend and a public holiday after my final submission was due. When they offered me the job they handed me a book about PL/SQL, and it made sense. I had been right to skip the database subject – it seemed simple and of little consequence. Just somewhere to store the values that the application needed. I was more interest in the algorithms and internal data structures that I’d be coding against the data.
However, once I had got into the job, i started to see that the paradigm I was dealing with was slightly different to the ones I’d learned about at uni. The difference was that most people didn’t really see it. The paradigm was that we were dealing with database applications. The databases were central to everything that our applications did. Sure, the applications would involve user interfaces, which is what most people saw as the critical bit, but I saw that the bit that really mattered was the database aspect. And the code that ran on the database was different again. I heard a lot about set-based algorithms, and quickly saw how to marry the concept of a set-based query with the row-based impact I had in my head. But even then I had got the paradigm wrong.
The misconception that I had was that the paradigm about database applications was the database-centric approach. I thought I had been able to discern this where others had thought that the key was the user interface or some other aspect. I knew that the data was the most important piece of the puzzle. That you needed to be able to protect and preserve that above all. That success was about making sure that the right stuff was happening in the database.
But I was wrong.
Yes, the database is important. It really is. I know that even if the user interface is gone, having the data can keep the business alive.
But the most important piece is the people.
Whichever people they are – users, customers, suppliers, operators, managers, whoever. They are the most important piece. The data needs to serve them. Sure I can make the database be quick, and that can make life less frustrating for the people. I can make the data tell stories and give insight, that can make life more interesting for the people. But the data is not what it’s about. The data is there to serve the people.
I think this is why I like being a consultant. I get to help people with their stuff. What I do for our customers doesn’t even always involve the database. Sometimes it’s solving problems without the database. Sometimes it involves doing data things that make me wince, because I know that I would never choose to do it that way if it wasn’t for the impact on the people. But that’s when I have to remind myself that my paradigm – the way I approach problems – should always be people-first. Not data-first.
