Zasadniczo masz 3 opcje:
-
Po prostu zapisz
userIda następnie pobrać użytkownika osobno. W ten sposób zawsze uzyskujesz optymalne wyniki pod względem świeżych danych. Ale oczywiście wolniej. W zasadzie to właśnie robi relacyjna baza danych. Baza danych SQL po prostu spojrzy na klucz obcy i pobierze dane według identyfikatora. -
Żyj z nieaktualnymi danymi. Przechowuj duplikat nazwy użytkownika w komentarzach. Czasami jest to pożądane zachowanie, ponieważ w ten sposób możesz reprezentować dane dokładnie tak, jak były one przechowywane. Oznacza to:Jeśli Jan utworzy komentarz, a później jego nazwa użytkownika zostanie zaktualizowana do Paula, nadal możesz zobaczyć, że został utworzony jako Jan. (Jest to szczególnie przydatne np. w przypadku faktur, gdy wskazujesz tam osobę i adres się zmienia, niż nie chcesz aktualizować adresu starej faktury)
-
Zaktualizuj wszystko, co zawiera nazwę użytkownika, gdy nazwa użytkownika zostanie zaktualizowana. To też nie jest złe, ponieważ nazwa użytkownika normalnie nigdy nie powinna się zmieniać. Więc odczyty zawsze będą szybkie, ponieważ nazwa jest przechowywana w komentarzu. A jeśli nazwa się zmieni, musisz zaktualizować wszystko, w co zaangażowany jest użytkownik. Jest to oczywiście powolne zadanie, ale ponieważ nie powinno się to odbywać co minutę, jest tolerowalne.
3.1 Możesz zoptymalizować rzeczy:jeśli zmieni się nazwa użytkownika, zostanie to gdzieś zapisane i zostanie zastosowane o północy. W ten sposób możesz zbierać wiele zmian nazw i aktualizować wszystko w tym samym czasie.
Jak widać:NoSQL to wybór . Możesz robić rzeczy, które najlepiej pasują do Twoich danych. Oczywiście zawsze jest to kompromis:wolniej/szybciej, więcej/mniej kodu do napisania, łatwiejszy/trudniejszy w utrzymaniu.
Podsumowując:
- Szybkie zapisy, spójne dane, wolne odczyty
- Szybki zapis, niespójne dane, szybkie odczyty
- Szybki zapis, szybki odczyt, dane stają się spójne po procesie aktualizacji, który może zająć trochę czasu. A proces aktualizacji jest oczywiście powolny.
