> 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.
Re:Running GitHub on Rails 6.0
by chipotle_coyote on Monday September 09, 2019 @03:17PM
(#20921337)
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.
Re:Running GitHub on Rails 6.0
by paulddraper on Tuesday September 10, 2019 @07:43PM
(#20935107)
This was more relevant when many products were like Confluence and JIRA...they would run on prem with the DBA's DBMS of choice.
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.)