Or is this not even a useful way of thinking in the NoSQL paradigm? Regardless, how would you go about mapping large amounts of users to large amounts of groups, or handling likes on posts, or handling tags?
I'm super curious to hear your thoughts!
For further actions, you may consider blocking this person and/or reporting abuse
Timeless DEV post...
The most used technology by developers is not Javascript.
It's not Python or HTML.
It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.
I'm talking about Git and version control of course.
Justin Ethier -
Elliot Brenya sarfo -
Md. Mobin -
Andrea Bellu -
Once suspended, cameronblandford will not be able to comment or publish posts until their suspension is removed.
Once unsuspended, cameronblandford will be able to comment and publish posts again.
Once unpublished, all posts by cameronblandford will become hidden and only accessible to themselves.
If cameronblandford is not suspended, they can still re-publish their posts from their dashboard.
Once unpublished, this post will become invisible to the public and only accessible to Cameron.
They can still re-publish the post if they are not suspended.
Thanks for keeping DEV Community safe. Here is what you can do to flag cameronblandford:
Unflagging cameronblandford will restore default visibility to their posts.
Top comments (8)
That's a quintessential relational data model, and document databases really aren't designed for that use case. It can be done, as Ankur demonstrates, but awkwardly and without the safeguards of foreign key constraints.
Document dbs shine when you have sets of hierarchies with few to no interrelationships. In other cases, it's like using a wrench to drive nails.
Hi, I see Tinder uses MongoDB and they use a M-M relationship with the swiping feature. How do you think that would work? Also, what DB do you recommend for M-M?
The ONLY truly viable way to ensure the integrity of data in Many to Many relationships is to use database engines which are designed to correctly handle foreign key constraints, RDBMs are the typical way to do this, many Modern RDBMs also handle JSON data extremely well and can store Documents in JSON columns whilst still maintaining full referential integrity. (Yes there are some who would suggest doing it in code, most who do so have never had to fixup the data messes this can and often does cause).
PostgreSQL (Amazon Redshift), MySQL 8 (Amazon RDS / Aurora MySQL 8), SQL Server (Amazon RDS SQL Server / Azure SQL Database), these three are very widely used and each have JSON functions which enable many of the functions of NOSQL databases to be implemented within an RDBMs.
Let's take students and course example..
You can create
Student{
_id:ID
name: String
courses: Array[ID]
}
Course{
_id:ID
name: String
}
Would it be slow to look up which students were in a particular course then, if there are, say, 100k students and 100k courses?
Let say if you have N students and M courses and if we store course Id in sorted order then the time complexity should be N*log(M).
We can also store list of student IDs in course document. Then the time complexity should be N or o(1) as mongo creates indexes on id.
Hi,
"We can also store list of student IDs in course document. Then the time complexity should be N or o(1) as mongo creates indexes on id."
=> This makes the insert function more complicated ? If you want to add 1 students with 10 courses, you will must insert user_id to courses.student_list (apply with all of 10 courses) and insert 10 course_id to students.course.
Everything has its price, sometimes you have to accept the complexity?
One of the biggest issues I found with this IDs approach is the MongoDB pipeline, as long as you don't have to do complex pipeline lookup on that many IDs.
There is a memory threshold on aggregates I guess that's why mongoose uses plain queries on the populate function.