When to use NoSQL instead of RDBMS?

Question

I've heard that if you have many "join"s in your RDBMS, that makes your service/app work slower.
And also, in case of RDBMS you have to define the strict schema for your tables.
I can't understand what are the pros and cons of NoSQL, can you bring a real-life example where NoSQL solves a real problem?

Answer 1

-------(2)-------
NoSQL:
User
{id: u1, uname: Burey}
{id: u2, uname: vardanator}
{id: u3, uname: Gandalf}
{id: u4, uname: Papa Smurf}
{id: u5, uname: Kramer}
Post
{id: p1, uid: u1, title: "Hello SL!", body: "How is.....", comments: [c1], likes: [l1, l2]}
Comment
{id: c1, uid: u2, body: "doing fine :]", likes: [l3, l4, l5, l6]}
Like
{id: l1, uid: u3}
{id: l2, uid: u4}
{id: l3, uid: u3}
{id: l4, uid: u4}
{id: l5, uid: u1}
{id: l6, uid: u5}

now this looks rather complex, but can be simplified:
you can for example skip the Like schema and just keep a list of user ids in the posts and likes

the usage with an actual collection schema can allow us to add additional fields more easily (timestamps for example)

and a last word regarding the lists (posts, comments, likes):

in the actual database they can be saves as references to the actual object, that's why i used names like c1, l1, l2, ......

various engines allow you to populate the actual object by the reference when querying the DB.

for more info you can check these:

https://www.sololearn.com/discuss/1156702/?ref=app
https://www.sololearn.com/discuss/753417/?ref=app

Answer 2

-------(1)-------
think of a message board with users, posts, comments to posts, and likes for the posts and comments

to describe this in a relational database, a possible solution would need the following tables:

id: row id
uid: user id
pid: post id
cid: comment id
body: just plain text of post/comment

USERS(id, uname)
POSTS(id, uid, title, body)
COMMENTS(id, uid, pid, body)
POSTS_LIKES(id, uid, pid)
COMMENTS_LIKES(id, uid, cid)

these tables could give you the ability to keep track of posts, comments, who liked what and so on.

* it would be possible to merge the POSTS_LIKES and COMMENTS_LIKES to one table like so:

LIKES(id, uid, pid, cid)
and determine the relation by pid (post id) or cid (comment id) *

we'll define possible schemas for the following collections: User, Post, Comment, Like

* keep in mind that every object is generated with a unique id throughtout the entire DB, that's why i ommit "id" field from each schema *

User(uname)
Post(uid, title, body, comments, likes)
Comment(uid , body, likes)
Like(uid)

one of the nice features of NoSQL is that it's actually structured as a document (in mongodb it's BSON format, which ia very similar to JSON).

this allows to have lists as fields

so the following post in SQL and NoSQL:

Burey: Hello SL!
~~~~~~~~~~~~~~~~
How is evreyone doing?
likes: 2
comments:
vardanator: doing fine :]
likes: 4

SQL:

USERS
id uname
1 Burey
2 vardanator
3 Gandalf
4 Papa Smurf
5 Kramer
POSTS
id uid title body
1 1 Hello SL! How is.....
COMMENTS
id uid pid body
1 2 1 doing fine :]
LIKES
id uid pid cid
1 3 1 NULL
2 3 NULL 1
3 4 1 NULL
4 4 NULL 1
5 1 NULL 1
6 5 NULL 1

Answer 3

-------(3)-------
my fingers hurt now ._.