Bez względu na to, jak ustrukturyzujesz cały dokument, potrzebujesz zasadniczo dwóch rzeczy. Jest to w zasadzie właściwość „licznika” i „listy” tych, którzy już opublikowali swoje „polubienie”, aby upewnić się, że nie ma przesłanych duplikatów. Oto podstawowa struktura:
{
"_id": ObjectId("54bb201aa3a0f26f885be2a3")
"photo": "imagename.png",
"likeCount": 0
"likes": []
}
Niezależnie od przypadku, istnieje unikalny „_id” dla Twojego „postu ze zdjęciem” i dowolnych informacji, ale potem inne pola, jak wspomniano. Właściwość „lubi” jest tutaj tablicą, która będzie przechowywać unikalne wartości „_id” z obiektów „user” w twoim systemie. Tak więc każdy "użytkownik" ma gdzieś swój własny unikalny identyfikator, albo w pamięci lokalnej, OpenId, czy coś, ale unikalny identyfikator. Pozostanę przy ObjectId na przykład.
Gdy ktoś przesyła „polubienie” do posta, chcesz wydać następujące oświadczenie o aktualizacji:
db.photos.update(
{
"_id": ObjectId("54bb201aa3a0f26f885be2a3"),
"likes": { "$ne": ObjectId("54bb2244a3a0f26f885be2a4") }
},
{
"$inc": { "likeCount": 1 },
"$push": { "likes": ObjectId("54bb2244a3a0f26f885be2a4") }
}
)
Teraz $inc operacja spowoduje zwiększenie wartości "likeCount" o określoną liczbę, więc zwiększ o 1. $push operacja dodaje unikalny identyfikator użytkownika do tablicy w dokumencie w celu wykorzystania w przyszłości.
Najważniejszą rzeczą tutaj jest prowadzenie rejestru tych użytkowników, którzy głosowali i tego, co dzieje się w części „zapytanie” oświadczenia. Oprócz wybrania dokumentu do aktualizacji według jego własnego unikalnego „_id”, inną ważną rzeczą jest sprawdzenie tablicy „lubi”, aby upewnić się, że aktualnie głosujący użytkownik już tam nie jest.
To samo dotyczy przypadku odwrotnego lub „usuwania” „podobnego”:
db.photos.update(
{
"_id": ObjectId("54bb201aa3a0f26f885be2a3"),
"likes": ObjectId("54bb2244a3a0f26f885be2a4")
},
{
"$inc": { "likeCount": -1 },
"$pull": { "likes": ObjectId("54bb2244a3a0f26f885be2a4") }
}
)
Najważniejszą rzeczą tutaj są warunki zapytania używane, aby upewnić się, że żaden dokument nie zostanie dotknięty, jeśli wszystkie warunki nie zostaną spełnione. Tak więc liczba nie zwiększa się, jeśli użytkownik już głosował, lub zmniejsza się, jeśli jego głos nie był już obecny w momencie aktualizacji.
Oczywiście odczytywanie tablicy zawierającej kilkaset wpisów w dokumencie w jakiejkolwiek innej części aplikacji jest niepraktyczne. Ale MongoDB ma bardzo standardowy sposób, aby sobie z tym poradzić:
db.photos.find(
{
"_id": ObjectId("54bb201aa3a0f26f885be2a3"),
},
{
"photo": 1
"likeCount": 1,
"likes": {
"$elemMatch": { "$eq": ObjectId("54bb2244a3a0f26f885be2a4") }
}
}
)
To użycie $elemMatch w projekcji zwróci tylko bieżącego użytkownika, jeśli jest obecny, lub po prostu pustą tablicę, gdy go nie ma. Dzięki temu reszta logiki aplikacji będzie wiedziała, czy bieżący użytkownik już zagłosował, czy nie.
Jest to podstawowa technika i może działać w takim przypadku, w jakim jest, ale powinieneś mieć świadomość, że wbudowane tablice nie powinny być nieskończenie rozszerzane, a także istnieje twardy limit 16 MB na dokumenty BSON. Tak więc koncepcja jest rozsądna, ale po prostu nie można jej używać samodzielnie, jeśli oczekujesz tysięcy „podobnych głosów” w swojej treści. Istnieje koncepcja znana jako „wiadro”, która jest szczegółowo omówiona w tym przykładzie dla projektu schematu hybrydowego, który umożliwia jedno rozwiązanie do przechowywania dużej liczby „polubień”. Możesz na to spojrzeć razem z podstawowymi koncepcjami tutaj, jako na sposób na robienie tego głośno.
