MongoDB - dětská a rodičovská struktura

Musíte zvážit typ dotazů, které budete muset provést, a jak často bude každý typ potřeba. Když jsem na něčem podobném pracoval, napadlo mě šest možných akcí:

• Udělejte něco s rodičem
• Udělejte něco s dětmi
• Udělejte něco s předky (rodiče rodičů, rodiče rodičů rodičů atd.)
• Udělejte něco s potomky (dětmi dětí, dětmi dětí dětí atd.)
• Změnit vztahy (přidat/přesunout/smazat uzly v hierarchii)
• Změnit hlavní data v aktuálním uzlu (např. změnit hodnotu v poli „title“)

Budete chtít odhadnout, jak důležitá je každá z nich pro vaši aplikaci.

Pokud většina vaší práce zahrnuje práci s uloženými daty pro určitý článek včetně jeho bezprostředního rodiče a potomků, první nápad je nejužitečnější. Ve skutečnosti je v MongoDB docela běžné umístit všechny potřebné informace do stejného dokumentu a ne na ně odkazovat externě, takže stačí načíst jednu věc a jen s těmito daty pracovat. Poslední čtyři akce v seznamu jsou však složitější.

Zejména v tomto případě budete muset procházet stromem, abyste získali předky a potomky, procházet prostředními dokumenty a sledovat cestu, i když vás může zajímat pouze poslední dokument v cestě. To může být pomalé pro dlouhé hierarchie. Změna vztahů může vyžadovat přesun velkého množství informací ve více dokumentech kvůli všem datům přítomným v každém z nich. Ale i změna jednoho pole, jako je „název“, může být nepříjemná, protože musíte vzít v úvahu skutečnost, že toto pole je přítomno ve více různých dokumentech, buď jako hlavní pole, nebo pod nadřazeným nebo podřízeným polem.

V podstatě váš první nápad funguje nejlépe ve více statických aplikacích kde data po prvotním vytvoření nebudete moc měnit, ale kde je potřebujete pravidelně číst.

Dokumentace MongoDB obsahuje pět doporučených přístupů pro manipulaci se stromovými (hierarchickými) strukturami. Všechny mají různé výhody a nevýhody, i když všechny usnadňují aktualizaci hlavních dat v článku tím, že to stačí udělat v jednom dokumentu.

• Rodičovské reference :každý uzel obsahuje odkaz na svého rodiče.
• Výhody :
  • Rychlé rodičovské vyhledávání (vyhledávání podle „_id“ =název vašeho dokumentu, návratové pole „rodič“)
  • Rychlé vyhledávání dětí (vyhledání podle „rodiče“ =název vašeho dokumentu, který vrátí všechny podřízené dokumenty)
  • Aktualizace vztahů je pouze otázkou změny „nadřazeného“ pole
  • Změna podkladových dat vyžaduje změny pouze v jednom dokumentu
• Nevýhody :
  • Vyhledávání podle předků a potomků je pomalé a vyžaduje procházení
• Odkazy na děti :každý uzel obsahuje referenční pole ke svým potomkům
  • Výhody :
    • Rychlé načítání dětí (vrácení pole dětí)
    • Rychlá aktualizace vztahu (stačí aktualizovat dětské pole tam, kde je potřeba)
  • Nevýhody :
    • Nalezení nadřazeného prvku vyžaduje vyhledání vašeho _id ve všech podřízených polích všech dokumentů, dokud jej nenajdete (protože nadřazený uzel bude obsahovat aktuální uzel jako podřízený)
    • Hledání předků a potomků vyžaduje procházení stromu
• Pole předků :každý uzel obsahuje odkaz na pole svých předků a svého rodiče
  • Výhody :
    • Rychlé vyhledání předků (k nalezení konkrétního není nutné procházení)
    • Snadné vyhledání rodičů a dětí podle přístupu „Rodičovské reference“
    • Chcete-li najít potomky, stačí vyhledat předky, protože všichni potomci musí obsahovat stejné předky
  • Nevýhody :
    • Je třeba se starat o udržování aktuálního pole předků i nadřazeného pole, kdykoli dojde ke změně vztahů, často ve více dokumentech.
• Materializované cesty :každý uzel obsahuje cestu k sobě - ​​vyžaduje regulární výraz
  • Výhody :
    • Snadné nalezení dětí a potomků pomocí regulárního výrazu
    • Může použít cestu k načtení rodiče a předků
    • Flexibilita, například hledání uzlů pomocí dílčích cest
  • Nevýhody :
    • Změny vztahů jsou obtížné, protože mohou vyžadovat změny cest napříč více dokumenty
• Vnořené sady :Každý uzel obsahuje pole „vlevo“ a „vpravo“, které pomáhá najít podstromy
  • Výhody :
    • Snadné načtení potomků optimálním způsobem pomocí vyhledávání mezi „left“ a „right“
    • Stejně jako u přístupu „Parent Reference“ je snadné najít rodiče a děti
  • Nevýhody :
    • Musíte projít strukturou, abyste našli předky
    • Změny vztahů zde fungují nejhůře než jakákoli jiná možnost, protože každý jednotlivý dokument ve stromu může být potřeba změnit, aby se zajistilo, že „vlevo“ a „vpravo“ má smysl, i když se něco v hierarchii změní.

Těchto pět přístupů je podrobněji probráno v dokumentaci MongoDB .

Váš druhý nápad kombinuje výše popsané přístupy „Rodičovské reference“ a „Odkazy na děti“. Tento přístup usnadňuje nalezení jak podřízených, tak nadřazených a usnadňuje aktualizaci vztahů a hlavních dat článku (ačkoli je třeba aktualizovat jak nadřazená, tak podřízená pole), ale stále je musíte procházet. najít předky a potomky.

Pokud vás zajímá hledání předků a potomků (a záleží vám na tom víc než na možnosti snadno aktualizovat vztahy), můžete zvážit přidání pole předků do svého druhého nápadu, aby bylo také snadné dotazovat se na předky a potomky. Aktualizace vztahů se samozřejmě stane skutečnou bolestí, pokud to uděláte.

Závěr:

• Nakonec vše závisí na tom, jaké akce jsou nejvíce potřeba. Protože pracujete s články, jejichž podkladová data (např. název) se mohou často měnit, možná se budete chtít vyhnout prvnímu nápadu, protože byste museli aktualizovat nejen hlavní dokument pro tento článek, ale všechny podřízené dokumenty a také rodič.

• Váš druhý nápad usnadňuje získání bezprostředního rodiče a dětí. Aktualizace vztahů také není příliš obtížná (je to určitě lepší než některé jiné dostupné možnosti).

• Pokud si opravdu chcete usnadnit hledání předků a potomků na úkor snadné aktualizace vztahů, zvolte zahrnout řadu odkazů na předky.

• Obecně se snažte minimalizovat počet požadovaných průchodů, protože vyžadují spuštění nějakého druhu iterace nebo rekurze, abyste se dostali k požadovaným datům. Pokud si ceníte možnosti aktualizovat vztahy, měli byste také vybrat možnost, která změní méně uzlů ve stromu (Rodičovské reference, Podřízené reference a váš druhý nápad to dokáže).