I often opt to use SQL instead of the canonical query builder, especially for queries that do not return individual models but aggregate values or the like. You can even mix-and-match to your liking, i. e. writing individual clauses of the query (select/where/join/having/count) in SQL and using the ORM for the others.
That's actually good to know (or perhaps be reassured on). While key-value stores have their place, I've wondered if the rise of NoSQL in web dev was triggered in part by the widespread move a few years beforehand to ORMs, which trained a generation of developers to look at databases through the lens of object relations rather than table relations. I'm (re-)learning Rails with the Pragmatic Studio's Rail 6 course currently, and reminded of why I liked it -- but in the last few years I've also come to renew my appreciation of pure SQL.
(I also suspect that the tradeoff of abstraction layers -- in exchange for having little to no database-specific functionality, we give up any and all specific to the database we're using -- may not be a good one, but that's a different argument.)
> I also suspect that the tradeoff of abstraction layers -- in exchange for having little to no database-specific functionality, we give up any and all specific to the database we're using -- may not be a good one, but that's a different argument.
Indeed. I'm currently in the process of porting my companies product from Firebase to Postgres. We're making full use of postgres-specific features where that makes sense. I can't see why we'd ever want to switch.
Yeah, that'd be my main argument here. In practice, I'm not sure switching database back ends happens that often once you're actually in production -- and when it does, it's usually moving between back ends that are so different you're going to be doing a lot of rewriting anyway.
I've seen programs switched out on top of databases more often than I've seen the reverse.
Most DBs are much, much better if you commit to them and actually use their features. I dislike the practice of treating them as interchangeable and think it's rarely a good idea.
That's actually good to know (or perhaps be reassured on). While key-value stores have their place, I've wondered if the rise of NoSQL in web dev was triggered in part by the widespread move a few years beforehand to ORMs, which trained a generation of developers to look at databases through the lens of object relations rather than table relations. I'm (re-)learning Rails with the Pragmatic Studio's Rail 6 course currently, and reminded of why I liked it -- but in the last few years I've also come to renew my appreciation of pure SQL.
(I also suspect that the tradeoff of abstraction layers -- in exchange for having little to no database-specific functionality, we give up any and all specific to the database we're using -- may not be a good one, but that's a different argument.)