По принцип имате 3 възможности:
-
Просто запазете
userIdи след това вземете потребителя отделно. По този начин винаги получавате оптимални резултати по отношение на свежи данни. Но разбира се е по-бавно. Това в общи линии прави една релационна база данни. SQL DB просто ще погледне външния ключ и ще извлече данните по id. -
Живейте с остарели данни. Съхранявайте дубликат на потребителското име в коментарите. Понякога това е желано поведение, защото по този начин можете да представите данните точно както са били, когато са били съхранени. Това означава:Ако Джон създаде коментар и по-късно потребителското му име се актуализира на Пол, вие все още можете да видите, че е създаден като Джон. (Това е особено полезно за т.е. фактури, когато посочите лице там и адресът се промени, тогава не искате да актуализирате адреса на стара фактура)
-
Актуализирайте всичко, което съдържа потребителско име, когато потребителското име се актуализира. Това също не е лошо, защото потребителското име обикновено никога не трябва да се променя. Така че четенето винаги ще бъде бързо, защото името се съхранява в коментара. И ако името се промени, трябва да актуализирате всичко, където участва потребителят. Разбира се, това е бавна задача, но тъй като не трябва да се случва всяка минута, е поносимо.
3.1 Можете да оптимизирате нещата:ако потребителското име се промени, това се съхранява някъде и се прилага в полунощ. По този начин можете да съберете няколко промени в името и да актуализирате всичко едновременно.
Както можете да видите:NoSQL е въпрос на избор . Можете да правите нещата, които отговарят най-добре на вашите данни. Разбира се, винаги има компромис:по-бавно/по-бързо, повече/по-малко код за писане, по-лесно/по-трудно за поддръжка.
Обобщено е:
- Бърз запис, последователни данни, бавно четене
- Бързо писане, непоследователни данни, бързо четене
- Бърз запис, бързо четене, данните стават последователни след процеса на актуализиране, който може да отнеме известно време. И процесът на актуализиране, разбира се, е бавен.
