re: Any NoSQL true believers out there? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Sometimes NoSQL is really important... but I really believe most apps should use a relational model for main stuff. It's not white and black, it a...
 

In our academy system, we have a track which consists of many workshops which has many modules, each module has many lessons.

That sounds like a classic RDBMS case!

We got 4 joins between the four tables... so each time the user opens the academy to see the lessons, we need to perform 3 sub queries (let alone the ugly long query for calculating the shown lesson percentage).

And what do you see wrong with that? 😯

Consider the other scenarios as well: what if you have to look for a particular lesson? You'll end up having to scan all of them!

I really think your use case gains nothing by using a NoSQL store. In fact, this loose data model may only present problems in the long run. If you're concerned about speed and number of queries (but do you have data to prove that it's actually affecting user experience?) go huge on caching (set up a Redis cluster, maybe?).

I'm not against NoSQL, please note, but convenience is short-lived while data models last forever, so I'm really, really skeptical of throwing away a relational model.

 

Here is where things go wrong:

dev.to/0xrumple/comment/5e8l

Consider the other scenarios as well: what if you have to look for a particular lesson? You'll end up having to scan all of them!

Looking them how? by title?

That's not our job, that's algolia's job ;)

I really think your use case gains nothing by using a NoSQL store

The most part I feel will get right, is the logical nesting of documents instead of m2m ugly relationships which have no actual benefit.

go huge on caching (set up a Redis cluster, maybe?).

We do caching as explained here:

dev.to/0xrumple/comment/5ebp

so I'm really, really skeptical of throwing away a relational model.

I'm posting this here to make sure we are taking the right decision :)

code of conduct - report abuse