Teraz, gdy już omówiliśmy walidację i podstawowe zasady w dłuższej divi z mangustą na górze.
Może czas przestać martwić się tylko jednym modelem wewnątrz naszej aplikacji.
W końcu nie jest niesamowicie częste, że będziemy mieli tylko jednego użytkownika lub
jednego użytkownika, bez żadnego innego zasobu wewnątrz naszej aplikacji.
Myślę więc, że dobrą praktyką lub dobrym sposobem na rozszerzenie tej aplikacji byłoby
dodanie innego rodzaju zasobów do naszych użytkowników.
I nie tylko użytkownicy, ale także inny rodzaj zasobu może trzymać się naszego tematu postów
tutaj.
Może moglibyśmy mieć listę lub zbiór różnych postów.
Tak jak użytkownik może utworzyć wpis, a gdy użytkownik utworzy wpis, będzie on w
pewnym sensie należał do nich, a co najważniejsze, możemy powiedzieć, że użytkownik ma wiele postów, ponieważ użytkownik może tworzyć wiele
różnych postów, gdy mówię post mam na myśli konkretnie, jak powiedzmy post na blogu lub coś podobnego.
Zastanówmy się więc, w jaki sposób dodalibyśmy kolekcję postów lub tak jak naprawdę nie chcę
teraz używać kolekcji słów.
Chcę tylko pomyśleć, w jaki sposób dodać do pomysłu PPO w naszej aplikacji.
Więc twoja pierwsza intuicja może być dobrze, stwórzmy nowy model mangusty, by reprezentować post.
W tej chwili mamy model mnichów dla użytkownika.
Zróbmy kolejną, która będzie stanowić post.
Więc jeśli to zrobimy, możemy skończyć z czymś takim.
W efekcie powstałby jeden typ modelu, na przykład użytkownik, który miałby nazwę, a także miałby model
innego typu z tytułem, z pewnymi podobnymi do tytułu posta na blogu.
Więc to byłyby dwa zupełnie różne zasoby.
Jest to podejście, nad którym właśnie tutaj patrzymy, co ma sens w
przypadku bazy danych typu sequel lub relacyjnej bazy danych wewnątrz beznadziejnej bazy danych, takiej jak Mongo.
Zaczynamy w pewien sposób przekręcić ten typ relacji między tymi dwoma modelami w pewien sposób.
Ważną rzeczą do zapamiętania jest to, że powiedziałem wyraźnie, że użytkownik ma wiele postów.
Tak więc, gdy pojawia się post pływający wokół jest zawsze związany z dokładnie jednym użytkownikiem, który
ma na uwadze wewnątrz naszej bazy danych Mongo.
Bardziej rozsądnym typem struktury danych może być raczej niż posiadanie
oddzielnej kolekcji użytkowników w oddzielnym zbiorze wpisów, zamiast tego wciąż ma jedną kolekcję użytkowników, a następnie
wewnątrz modelu użytkownika możemy mieć listę różnych postów. które należą do nich.
Więc może nasz użytkownik Joe z imieniem Joe ma właściwość post, która zawiera trzy posty
wewnątrz, z których każda ma odrębną właściwość tytułu.
Ta koncepcja gniazdowania rekordów lub asocjacji gniazdowania zamiast wyrzucania zupełnie nowych kolekcji jest sednem tego, co sprawia,
że zasada Mungo Mongo mówi o wiele więcej na temat możliwego schematu projektowego w przyszłości, ale na
razie chcę po prostu iść tą ścieżką i zobaczymy, jak by to
było, gdybyśmy mieli kolekcję użytkowników, gdzie każdy użytkownik mógłby mieć listę postów, które można w niej
umieścić.
Każdy użytkownik może mieć wiele postów.
To jest nasz cel.
OK, po prostu myśl o tym w inny sposób.
To jest nasz model użytkownika lub diagram naszego modelu użytkownika.
Obecnie nasz model użytkownika ma schemat użytkownika.
Schemat użytkownika ma nazwę.
Licznik postów i sugeruję, abyśmy dodali do niego możliwość posiadania tablicy takiej jak wiesz, że
powinna tu znajdować się lista wpisów.
Następnie będziemy mieć schemat postu, który zawiera tytuł.
Jedno co powiem teraz i powtórzę to prawdopodobnie kilka razy
od teraz do następnej sekcji jest to, że za każdym razem, gdy osadzimy dokument w ten sposób, nie
utworzymy osobnego modelu, jakbym konkretnie użył słowa model tutaj, aby reprezentować zagnieżdżony zasób, więc
nie zrobimy modelu postu.
Zamiast tego zrobimy tylko schemat postu, więc zrobimy coś rzeczywistego lub napiszemy trochę kodu, żeby
opisać, jak powinien wyglądać post wewnątrz użytkownika.
Ale nie zrobimy wyraźnej kolekcji mangusty lub bardziej wyraźnego modelu mangusty wokół postu.
Powodem tego jest to, że modele mangusty, takie jak nasz model użytkownika, są tworzone w celu reprezentowania odrębnych kolekcji.
Siedzą w naszej bazie danych D-B.
Ale w przypadku postów nie jest to odrębna kolekcja.
Wiesz i Rogow Monga, że nie będziemy mieli tutaj listy postów.
Będziemy mieć tylko listę użytkowników lub zbiór użytkowników, a każdy z nich może
mieć listę postów.
Z tego powodu zrobimy model postu, który będzie tworzył tylko schematy pocztowe.
DOBRZE.
Więc dużo gadania o poście i osadzaniu i wszystkich tego rodzaju dobrych rzeczach.
Kontynuujmy następną sekcję i zobaczmy dokładnie, jak zamierzamy stworzyć schemat postu i osadzić go w
pewien sposób w naszym modelu użytkownika.