In most organizations a database is broader than any individual application - both in lifecycle and scope. So it makes sense that this state exists in a different way.

I suspect it’s because people never learned to use them, but they did learn to use the ORM.

▲

ameliaquining 3 days ago | parent [-]

The textbooks all say that, but is it really true in practice? I suspect it's a bit of holdover conventional wisdom from an earlier era of software. Usually, when I've created a database for a particular app, it was never used by anything else besides that app (and manual queries, for which versioning is mostly not relevant).

You might choose to have a set of views and functions that are versioned separately from your app, for the same reasons you might choose to set up a microservice. But as with microservices, it should be a deliberate decision that you make because you're getting something out of it that outweighs the complexity costs and version-skew headaches; it should not be the default way to do composition.

	▲	baq 3 days ago \| parent \| next [-]
		It’s absolutely true. Nobody should be building a microservice architecture for a product without a proven market fit, monolithic development is just faster at this stage, and when you get around to scaling it once you outgrow it (which should be much later than conventional microservice wisdom agrees) the database isn’t the bottleneck anyway and hence stays monolithic (don’t confuse with adding shards).
	▲	monkeyelite 2 days ago \| parent \| prev [-]
		Making two views and deprecating one is actually the simplest possible compatibility strategy - just like adding a new version of a function to a header.