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 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!