> 2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL.
In my experience using any ORM will bite you sooner or later and you'll end up bypassing it and writing SQL manually. Last case we had were a couple queries that went from double digit seconds to instant as we rewrote them natively.
Both have their place. I agree that for complex queries, nothing beats raw SQL. However, for simple, straightforward queries fetching data from a single table without JOINs/etc, the ORM is generally easier.
just a nitpick: MySQL comes with the same default engine (InnoDB) for at least 10 years now. It is recommended by docs and it is what everyone uses unless they go out of their way to install some very specialized storage engine.
In my years of consulting I have yet to see someone not using just InnoDB in MySQL.
Seconded. I prefer high level abstractions in general. However when it comes to ORMs; I wouldn't go anywhere near them. Admittedly there's a sweet spot where you could hand-pick ORM libraries such that you hand-code the queries and they only map query results to your objects. But to achieve that you need to wade through documentations and some undocumented APIs. So developers usually go all-in on ORMs. A big mistake.
Do you have any resources you can recommend about using the DB for more than just a dumb datastore?
The first thing I'd be concerned about is how do you manage changes? Code is easy to version control, deploy and roll-back. Database state and things such as triggers, stored procedures, etc, less so.
Not just Rails, any webdev group without the oversight of a DBA/Architect, and a penchant for simplistic ORM (mis)use plus uncorrected opinions around 'webscale' state persistence.
I think I've used Rails seriously only once or twice in my professional life but yeah, mostly treat data-stores as just dumb stores in most projects, unless it has some special requirements.
TL;DR: Everything has its place, stop implying you should never use use something.
> Don't use MongoDB.
Don't use MongoDB for something that should be in a relational DB. Use it as the document DB it is. Use the right tool for the right job. Mongo and other document DBs have their place.
> Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. Almost certainly Postgres.
Hard disagree. I've used many of the ORMs in different popular frameworks. They work well, save time, and are especially good for simple queries. They have their place, just as SQL does.
> Especially don't use Mongoid.
Unfortunately it's the go-to Ruby library for mongo. This could be an argument for not using mongo with Ruby. It could be an argument for creating an alternative. But simply saying don't use it isn't practical for many people.
Mongo is a nightmare when things get more complex, document based DBs don't work well. It's hard to say why, but strange things tend to happen
Ether use something like Firebase which manages everything for you, I use Firebase extensively for almost all of my side projects.
It's basically magic. I'm so hooked I ended up using Firebase even though I needed to talk to AWS apis as well. Not fun...
Edit: I would NOT use Firebase for a corporate project, there's a very strange feeling of not really being in control