I think that with the last paragraph you just nailed the issue. You can treat a database as "an interchangeable storage layer" or not.
The thing is to make this a design choice rather than anything else. For instance, I worked here in Argentina for about ten years in a company that develops an ERP. When I first started, the ERP was designed to work with several relational database engines. A couple years later, due to a partnership, they decided to work exclusively with one vendor.
Having made that shift, they started to migrate bussiness logic to the database, in order to get more performing querys, etc.. It's been a positive change.
But, what if you want to develop something to work with several database engines? You should then not abandon the "interchangeable storage layer" principle.
What I'm trying to say is that the answer to the question I propose is not an absolute one.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I did start my answer by saying it's not an either/or proposition for that very reason, among others :)
Sometimes you have to build something that can be dropped on top of any more-or-less standards-compliant RDBMS with minimum fuss, so you sacrifice architectural elegance for compatibility. It's kind of a crappy situation to be in, especially if there are things that nonstandard features could do much more elegantly for you, but it happens. Like materialized views can take a lot of pain out of preprocessing large amounts of data -- but if you need to be able to support MySQL, you're stuck with tables and procedures.
I think that with the last paragraph you just nailed the issue. You can treat a database as "an interchangeable storage layer" or not.
The thing is to make this a design choice rather than anything else. For instance, I worked here in Argentina for about ten years in a company that develops an ERP. When I first started, the ERP was designed to work with several relational database engines. A couple years later, due to a partnership, they decided to work exclusively with one vendor.
Having made that shift, they started to migrate bussiness logic to the database, in order to get more performing querys, etc.. It's been a positive change.
But, what if you want to develop something to work with several database engines? You should then not abandon the "interchangeable storage layer" principle.
What I'm trying to say is that the answer to the question I propose is not an absolute one.
I did start my answer by saying it's not an either/or proposition for that very reason, among others :)
Sometimes you have to build something that can be dropped on top of any more-or-less standards-compliant RDBMS with minimum fuss, so you sacrifice architectural elegance for compatibility. It's kind of a crappy situation to be in, especially if there are things that nonstandard features could do much more elegantly for you, but it happens. Like materialized views can take a lot of pain out of preprocessing large amounts of data -- but if you need to be able to support MySQL, you're stuck with tables and procedures.
Yes, I agree!