i’am really new on MongoDB, but I searched a lot. In the Forum in the Docs,…
As it looks like this is the MongoDB way:
If I have an app with
user
post
commets
likes
follower
uploads
reviews
messages
…
I should store my data like:
reviews
user: { name: …, profile_image: (url) }
title
description
rating
posts:
user: { name: …, profile_image: (url) }
title
description
upload:
user {}
path
reviews: { review schema with users }
aaaand so on.
But I don’t find, how to handle how to handle a user-name change.
Yes, maybe I can store the _id from the User in the User data.
But is the right way to do many of maybe really big loops to update the user name?
What if (let me dream guys :D) if my project will reach 1mrd user with 100Mrd posts.
How long an username-change will run?
To be realistic:
I think it’s a real problem even for smaller projects. If I have a car and I will store every spare-parts within one document maybe one screw is in many documents, may as array. and now, the manufacture will change the name or length.
is mongo a bad decision for project like that?
why I don’t find any tutorial or documentation for that (maybe aim just stupid )
Of course not. this design question is not specific to a database. Whatever you use, you face the same question.
Your requirements matter. Do you have to always show “update to date” user name? (e.g. if you change user name on teamblind, your old posts still show old name).
How frequent the user names can be changed? Any hard rule on that ? (e.g. at most once a month).
And more…
There are only two options going forward you either only reference to the user with an id or simply duplicate the user info every where. You just need to decide which one fits your case better, based on requirements.
Like in the most “social” Projects you can change your name 1x in three month or something like that.
So normally it looks like to embed the name in all collections.
but imagine that e.g. at twitter. Barack Obama change his name to Barack Obama is the best and on 133.000.000 relations you need to update the name on the “follower” collection.
and the idea behind most projects is or should be going as big as you can.
iam really unhappy with that, caus it looks like to me, that embedding is the way you go, but it doenst make sence if the data need to change over more than a few collections with a few data.
(my english is not the best, so maybe it sounds more negative than it should )
Update 133 million relation once and the day M. Obama change his profile name.
Lookup M. Obama current profile name every single time someone reads one of his publication.
Which use-case is the most frequent? Changing profile name or reading the name of a publication.
Do you want to slow down the most frequent use-case so that your rare use-case is faster?
Do you want to slow down the rare use-case so that your most frequent use-case is a lot faster?
Slowing down the most frequent use-case slows down the whole system most of the time.
Slowing down the rare use-case slows down the whole system on the rare occurrences of the use-case.
Agree but early optimization is useless as it delays your project.
Make it work.
Make it work correctly.
Then make it work correctly and fast.
)
)