You are sitting at your screen reading a blog about the death of monolithic databases:
“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”.
And you agree.
Well, you may be right, sometimes, but I assume you don’t agree with the following two statements:
A transaction has nothing to do with a customer and it doesn’t matter if you have a transaction without knowing who the customer was.
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”.
If referential integrity stops you splitting up the application into a service-orientated architecture, it could be that the requirements were misunderstood 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 other than handling 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 make 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.
Perhaps your understanding of “data” differs from mine, and it is upsetting to you to think that the data generated by your service isn’t actually yours, but that of the business, and the business has additional uses for it, but doesn’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 audibility 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!
You may also be interested in reading the counter-argument: Foreign Keys, Don’t Go There.