lulmerchant

There's an element in New Zealand that has a blindly hysterical anti-nuclear stance. Then there are others who understand that nuclear energy is one of the cleanest and safest forms of energy, and that refusing to admit American naval vessels into our waters is just a pointless diplomatic affront to our strongest ally.

There's an excellent reason to not have nuclear energy in New Zealand, which is that we don't need it. We already have 80% renewable electricity production, and we could realistically bridge that gap with cheaper methods than a nuclear power plant. However, just being "anti-nuclear" for the sake of being "anti-nuclear" isn't one of them.

"microservice" is certainly a buzzword, but it's not just service-oriented architecture. Mircoservice architecture is modular design, with all the advantages of effectively infinite scale, incredibly flexible orchestration, and the resilience provided by the public cloud providers. It has it's own set of challenges, and it isn't the right solution for every problem. But it can be fantastic when used properly. I've written plenty of well performing API endpoints in microservices, and I've also done a fair bit of business process automation with them.

I have a slightly different perspective. I think defaulting to NoSQL is simply removing a mature toolset from the developers kit, that they would have a lot of great use cases for.

If you use it in the wrong places, then that almost certainly means increases complexity where you don't necessarily have to. Whether or not that results other positive behaviours seems a bit beside the point to me.

If you managed a team of rock climbers, you could say "I prefer it when my rock climbers don't use safety ropes. It improves their climbing, because if they make a mistake, they'll fall to their death". It could be 100% true, but it doesn't mean you shouldn't simply be picking the right tools for the job.

My background is in financial applications, where an inconsistent state can literally be a multimillion dollar problem, so maybe my perspective is skewed a little. But FKs and other constraints are simply used to outright enforce consistency, in my experience at least. If you rely on your custom business logic to maintain consistency, then you leave yourself open to the possibility of breaking that in some way, and if you do, who says you'll notice right away? What if you don't notice for 6 months, and then realise that you have a billion transactions that have some form of integrity compromise?

Complexity obviously makes this problem more serious, but something like this can easily occur at any scale of complexity or transaction volume. If you try to commit some code that breaks the integrity of an important relationship in some way, or even if you just want to run an arbitrary statement directly against the database, then you want the DB to throw an error.

All the Oracle DBAs out there are in for some suffering. Forget the cost of 30% extra compute, what about the 30% increase to Oracle licensing?