> Databases are a miracle product. If you think of an application as a car, the database is the engine.
Yeah - you're totally right. Thats kind of why I'm complaining about them - because we use them so much I think the potential benefits from improving more them are massive.
The modern web stack is a mess, and changes all the time. But there's a handful of features we need in just about every application - login, update feeds, data-based rendering (computed views), etc. But stored procs aren't good enough - they're inaccessible, hard to debug and usually require their own (non-standard, barely known) language to develop in. So lots of developers write functions outside of the database through multiple queries, and in doing so will often break the database's transactional consistency model.
Databases have managed to stick around with us throughout the evolution of the web. I'm being critical, but I'm doing it out of love. I'm saying that databases have the potential to provide so much more to the modern web ecosystem than just data storage. They could do access control, and run stored proc-equivalent functions or computed views from whatever languages my app is written in. If I need some complicated data flow where data needs to be updated in realtime in a secondary db (like elasticsearch), that should be dead simple to do too. I didn't get into it in that article but I believe we should be able to extend our databases to share data flow logic between applications. Or just build a lot of this stuff into databases so its reusable between projects.
Databases are a miracle product. If you think of an application as a car, the database is the engine.
The idea that you have a platform that can do everything without the abstraction of a separate data storage/query platform, that exists too. I'd argue that FileMaker, Lisp, MUMPS, and a few others basically do this in different ways. I used to be a DBA at a company where the entire company ran on Informix 4GL code (which was sort of like the Informix version of PL/SQL) within the database. Also a similar approach.
But... they also have significant drawbacks. You're permamently married to that app/database stack. If any component of the system doesn't scale... you're fucked.
By chunking out the solutions to include databases, app tiers, etc, you gain complexity but lose a lot of risk. If you cannot afford Oracle anymore, you can invest in labor to move to Postgres. If you're hitting a limitation with MySQL, you can move to Oracle. If you wrote your app in PHP, it goes viral, and you cannot scale it, you can migrate to a Java Application Server layer.