Mamy teraz pewien poziom znajomości typowych operacji z użyciem mangusty.
Przeszliśmy przez wszystkie nasze zasoby.
Rozmawialiśmy o dokumentach podrzędnych walidacji i wirtualnych polach.
Zdecydowanie wszystkie podstawowe pojęcia w świecie mangusty w tej sekcji będziemy poruszać
się trochę i zaczniemy trochę mówić o tym, jak projektujemy duże bazy danych Mongo DB.
W tym momencie mamy po prostu kolekcję użytkowników i to wszystko.
Jak w zasadzie nic innego.
Tak, użytkownicy mogą mieć osadzone w nich posty, ale generalnie nie ma tu
zbyt wielu danych lub wielu relacji.
W tej sekcji zaczniemy zastanawiać się nad różnymi sposobami, w jaki moglibyśmy
zaprojektować ten schemat użytkownika.
To, co mamy tutaj, zdecydowanie działa.
Jest w 100 procentach poprawny, ale z pewnością istnieją pewne niedociągnięcia, które pojawią się po
umieszczeniu postów wewnątrz użytkownika.
Porozmawiajmy więc o tym, jakie będą te niedociągnięcia.
Przejdę do makiety na aplikację, którą możemy zbudować, korzystając ze schematu użytkownika,
który właśnie skonfigurowaliśmy.
Tak więc w tej aplikacji internetowej możemy sobie wyobrazić, że patrzymy na listę postów na
blogu lub jak listę postów, takich jak ten sam typ postu, który przechowujemy w modelu użytkownika, teraz
każdy post ma tytuł co odzwierciedla się po lewej stronie, a następnie autor lub właściciel postu
znajduje odzwierciedlenie po prawej stronie.
Mamy więc z pewnością wystarczająco dużo danych, aby stworzyć ekran, który wygląda tak, jak należy.
Zdecydowanie mamy listę użytkowników, których możemy pobrać z naszej bazy danych i na pewno mamy kilka wpisów na blogu,
które należą do każdego z naszych użytkowników.
Zamierzam zgodzić się z twierdzeniem, że być może skonfigurowany przez nas schemat nie spowoduje wyświetlania tego rodzaju obrazu
tutaj.
Najłatwiejszą rzeczą na świecie jest połączenie i oto dlaczego chcę, abyś przez chwilę zastanawiał
się nad rodzajem zapytania, które musielibyśmy napisać, aby uzyskać listę wpisów na blogu należących do wielu użytkowników na
ekranie.
Tak więc kluczem tutaj, jak prawdziwym symbolem wieloznacznym, który rzuca w równanie, jest to, że
chcę konkretnie publikować posty od różnych użytkowników na tym jednym ekranie.
Możemy napisać zapytanie, które wygląda na coś podobnego, gdy mówimy "OK" znajdź listę użytkowników lub
po prostu wypędź wszystkich użytkowników z mojej kolekcji użytkowników, a następnie dla każdego użytkownika pobierz listę
postów i zmontuj je na jednej liście wpisów.
Tak właśnie działa ta płaska mapa i możesz sobie wyobrazić, że ta
środkowa linia właśnie tutaj chwyta wszystkie posty każdego z tych użytkowników, które właśnie sprowadziliśmy.
I tak w końcu stworzysz tablicę lub listę różnych postów, które moglibyśmy pokazać naszemu
użytkownikowi lub komukolwiek, kto faktycznie korzysta z naszej aplikacji internetowej.
A więc oto powód, dla którego to podejście byłoby trochę trudnym.
Po pierwsze, kiedy budujemy tę listę postów na blogu dla użytkownika lub użytkownika, prawdopodobnie nie
chcemy wyświetlać nieskończonej listy.
Najprawdopodobniej chcemy pokazać tylko listę 10 postów lub 20, 30, 40 lub 50, lub coś
w tym rodzaju, jesteśmy tylko skończoną listą postów i prawdopodobnie chcemy się upewnić, że jest to runda
parzysta, kiedy użytkownik wchodzi na naszą stronę, zawsze gwarantuje, że na ekranie pojawi się
dokładnie 10 wpisów.
W przypadku tego typu zapytań, które mamy tutaj, ściąganie dokładnie 10 postów jest zaskakująco trudne.
Jeśli pójdziemy i znajdziemy każdego użytkownika w naszej bazie danych, to na pewno mamy pewność, że wiecie,
w zależności od wielkości naszej aplikacji i liczby zarejestrowanych użytkowników.
Może dostaniemy jak wiele wielu blogów znacznie więcej, niż byśmy chcieli.
Może dostaniemy z tego jak tysiąc flip postów.
Chcemy więc nieco okiełznać tę zabawę.
Dobrze.
Chcielibyśmy się upewnić, że nie otrzymamy 1000 postów, więc być może znajdziemy sposób na ograniczenie liczby użytkowników,
których znajdziemy w danym momencie, aby po prostu wysunąć 20.
Po prostu daj mi 20 użytkowników. Weźmy wszystkie posty na blogu, a następnie spróbuj uzyskać w sumie
10 z tych użytkowników.
Więc nawet gdybyśmy znaleźli sposób na ograniczenie liczby użytkowników, których pobraliśmy, nawet gdybyśmy właśnie
powiedzieli. Po prostu daj mi 20 użytkowników z bazy danych, nadal będziemy mieć problem, co by się
stało, gdyby tych 20 użytkowników, którzy pobieramy W ogóle nie pisał żadnych postów na blogu, więc nasz kod właśnie tutaj tworzyłby
listę bez postów.
Tak więc to, co próbuję tutaj zdobyć, to to, że kiedy zaczynamy pisać
posty na blogu wewnątrz modelu użytkownika, uzyskanie dostępu do listy zbiorczej wszystkich postów, które mamy, staje się naprawdę trudne,
zaczyna być zdecydowanie trudniejsze niż to musi być.
Plusem systemu, który zebraliśmy, ponieważ nie chcę bagatelizować żadnego
z upides, jest to, że znalezienie wszystkich stanowisk związanych z bardzo szczególnym użytkownikiem jest bardzo proste.
Więc gdybym zmienił tę makietę tutaj i powiedział, że chcę tylko zobaczyć wszystkie posty przez jednego
użytkownika, jak tylko pokazuje posty Alexa, nagle schemat, który zebraliśmy działa naprawdę bardzo dobrze, ponieważ
możemy po prostu znajdź naszego użytkownika Alexa, a następnie wyślij wszystkie jego posty do
dokumentu HTML H.
Więc z pewnością istnieją pewne zalety i wady tego podejścia, jeśli chodzi o wylistowywanie
zagnieżdżonych dokumentów, kontynuujmy następną sekcję, a my porozmawiamy o jednej z pozostałych różnic, to są
rodzaje wyzwań, które możemy mieć, używając tego zagnieżdżonego bloga post lub ten zagnieżdżony
sposób postu wewnątrz wyimaginowanej aplikacji.