[kurtbuilds]

Three easy lessons:

1. Don't use MongoDB.

2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. Almost certainly Postgres.

3. Especially don't use Mongoid.

[999900000999]

Even though I hate SQL with a passion, I agree with this 100%.

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

[cpursley]

Supabase is a good option these days.

[nottorp]

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

[Nextgrid]

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.

[zestyping]

And another:

4. Don't design an API that mixes fluent style (methods are like infix operators) with conventional style (methods are like prefix operators).

Fluent methods should never take multiple operands. It's a terrible, horrible, no-good, very bad idea.

[flubflub]

I think the default should be named prefix operators. Then you can have infix operators that are aliases.

This is a problem in Haskell with infix operators being directly defined I would argue.

I disagree that infix and prefix should not be mixed. Although there is a special hell for people who use + with non-commutative operators.

[radicality]

Could you comment on why you recommend Postgres (vs say mysql)? I know mysql well but haven’t had much exposure to Postgres.

[sam_lowry_]

Postgres implements the SQL standards however awful they are.

MySQL is a bunch of different engines that share a meaningful subset of SQL.

Somehow, Postgres got more popular lately, probably because it makes migrating from Oracle easier.

[vishnugupta]

> 2. Don't use high level ORMs.

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.

[forty]

I agree with the 3 lesson, but here I find the main problem is the lack of test. And weirdly the author doesn't seem to have noticed it.

[kevingadd]

If Postgres feels too heavy, don't worry! Just use SQLite, and swap in Postgres later once you need to.

[cpursley]

I guess this is a Rails thing where people treat the db as a just dumb store.

[driverdan]

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.