Guest author Pete Libman writes:
You are sitting at your screen wearing a t-shirt with some witty clever tech joke on it, reading some blog written by a bloke who probably looks a lot like the guy from the comic shop in The Simpsons.
Monolithic databases are so 80s, inflexible, they are an obstacle to change. Referential integrity stops us implementing service orientated architecture, and they cannot be harmonised with continuous delivery.
Do you agree?
Well, he may be right, sometimes, but;
Do you think that a transaction has nothing to do with a customer or that it doesn’t matter if you have a transaction and but you don’t know who the customer was?
Do you think it is okay that we took the money and the payment went through but we lost all record of it because the message “got lost”.
Do you ever think that if referential integrity stops you splitting up the application into a service orientated architecture that maybe they misunderstood the requirements or that the design is just plain WRONG. Heaven forbid that the database might actually validate input without you having to write some code to do it, although you will have to handle the error it throws when the customer Id you passed doesn’t actually exist.
Pipe (delimited) dream visions of utopian independent non-shared environments are worthy of their own dystopian novel by Ira Levin. It’s the cohesiveness and integrity of the data that makes it information, and not gossip and chatter. It’s not just about rendering a page in a nano second, if you can’t follow the cradle to grave thread of data, simply and easily, you are heading for disaster and wasting its power. You can split up the monolithic database and have your micro services, but you will always have shared architecture.
Let’s be frank, you don’t understand “data” in the same way as database people do, but you got upset because someone suggested the data generated by your service wasn’t actually yours, but that of the business, and the business had other uses for it, and didn’t want the expense and time of duplicating it a trillion times.
Be honest though, how much of your code is actually anything to do with the database interactions? 1% or 2%?
Of course there are times when you “shouldn’t use a database”. If you are storing non-persistent data in the Db then you need your head examining, but let’s use the technology that is most appropriate. Databases (and with my own set of biases I would say particularly Oracle) are good at what back in the day we used to call privacy and now you call security (keeping it from prying eyes) and what we used to call security which I think you now call security (integrity, persistence and availability). It’s good for slicing, dicing, cubing or whatever else you want to call data mining. It is also pretty good at auditability when the tax man or GCHQ suspect you might be naughty.
But I can understand your pain, can you understand mine? Let’s come to a deal. You look after your services and we will look after the data. I’ll relieve you of your pain of writing those inefficient queries that take 5 seconds to return data and you can stop spinning up a new SQL Server instance because you want two new tables. Actually, you don’t care how or where the data is stored, so we will do that for you. We can provide the database and you can use our interfaces, and can save each other a world of pain!