Istnieje kilka „bardzo przydatnych przypadków”, w których w rzeczywistości próba utworzenia „unikalnego hasza” na zawartości tablicy w rzeczywistości „wchodzi na przeszkodzie” niezliczonym problemom, które można łatwo rozwiązać.
Znajdowanie wspólnego dla „mnie”
Jeśli na przykład weźmiesz "użytkownika 1" z dostarczonego przykładu i uznasz, że masz już załadowane dane i chcesz znaleźć "te, które są wspólne ze mną" na podstawie dopasowanych "itemsIds" z tego, co ma bieżący obiekt użytkownika, to tam są dwa proste podejścia do zapytań:
-
Znajdź „dokładnie” to samo: To miejsce, w którym chcesz sprawdzić inne dane użytkowników, aby zobaczyć tych użytkowników, którzy mają te same „dokładne” zainteresowania. Jest to proste i „nieuporządkowane” użycie
$wszystkie
operator zapytania:db.collection.find({ "itemsIds": { "$all": [399957190, 366369952] }, "userId": { "$ne": 1 } })
Co zwróci "użytkownik 3", ponieważ są to te, które mają "oba" wspólne wpisy "itemsIds". Kolejność nie jest tutaj ważna, ponieważ zawsze jest to dopasowanie w dowolnej kolejności, o ile obaj są tam. To jest inna forma
$i
jako argumenty zapytania. -
Znajdź „podobne” wspólne dla mnie: Co w zasadzie jest pytaniem „czy masz coś, co jest takie samo?” . W tym celu możesz użyć
$in
operator zapytania. Będzie pasować, jeśli „jeden” z określonych warunków zostanie spełniony:db.collection.find({ "itemsIds": { "$in": [399957190, 366369952] }, "userId": { "$ne": 1 } })
W tym przypadku „zarówno” „użytkownik 2” jak i „użytkownik 3” będą pasować, ponieważ „przynajmniej” współdzielą „jeden” z określonych warunków, a to oznacza, że mają „coś wspólnego” z danymi źródłowymi zapytanie.
W rzeczywistości jest to inna forma
$lub
operator zapytania i tak jak wcześniej, pisanie w ten sposób jest dużo prostsze i bardziej zwięzłe, biorąc pod uwagę warunki, które mają zostać zastosowane.
Znajdowanie wspólnych „rzeczy”
Istnieją również przypadki, w których możesz chcieć znaleźć rzeczy „wspólne” bez posiadania podstawowego „użytkownika”, od którego można by zacząć. Jak więc stwierdzić, że „użytkownik 1” i „użytkownik 2” mają te same „itemIds”, lub w rzeczywistości, że różni użytkownicy mogą mieć tę samą wartość „itemIds” indywidualnie, ale kim oni są?
-
Uzyskaj dokładne dopasowania: To oczywiście tam, gdzie patrzysz na wartości „itemsIds” i
$grupa
oni razem. Ogólnie rzecz biorąc, „zamówienie jest ważne” tutaj, więc optymalnie masz je „zamówione w przedsprzedaży” i konsekwentnie, aby to było tak proste, jak:db.collection.aggregate([ { "$group": { "_id": "$itemsIds", "common": { "$push": "$userId" } }} ])
I to wszystko, o ile zamówienie już istnieje. Jeśli nie, możesz zrobić nieco dłuższą formę, aby wykonać „zamawianie”, ale to samo można powiedzieć o generowaniu „haszytu”:
db.collection.aggregate([ { "$unwind": "$itemsIds" }, { "$sort": { "_id": 1, "itemsIds": 1 } }, { "$group": { "_id": "$_id", "userId": { "$first": "$userId" }, "itemsIds": { "$push": "$itemsIds" } }}, { "$group": { "_id": "$itemsIds", "common": { "$push": "$userId" } }} ])
Nie „super” wydajna, ale sprawia, że zawsze zachowujesz porządek przy dodawaniu wpisów do tablicy. Co jest bardzo prostym procesem.
-
Zwykłe „użytkownik” na „elementy”: Co jest kolejnym prostym procesem abstrahującym od powyższego z "rozkładaniem" tablicy pod
$unwind
, a następnie po prostu grupowanie wstecz:db.collection.aggregate([ { "$unwind": "$itemsIds" }, { "$group": { "_id": "$itemsIds", "users": { "$addToSet": "$userId" } }} ])
I znowu, po prostu prosty agregator grupowania
$ addToSet
wykonuje zadanie i zbiera „różne wartości userId” dla każdej wartości „itemsIds”.
To wszystko są podstawowe rozwiązania i mógłbym kontynuować z „ustawianymi skrzyżowaniami” i czym nie, ale to jest „podkład”.
Nie próbuj obliczać "haszy", MongoDB i tak ma dobry "arsenał" do dopasowywania wpisów. Używaj go i „nadużywaj”, aż się zepsuje. Następnie spróbuj mocniej.