Databáze Mongodb Schema Design se sdílenými daty

Vaše výzva vychází ze skutečnosti, že Prop_Info musí být načteno oběma dotazy. Díky tomu je obtížné zjistit, ve které kolekci Mongo by měl bydlet.

V MongoDB vytvoříte schéma dokumentu s ideálním cílem, aby jeden dokument obsahoval všechny informace, které potřebujete vzhledem k vašim vzorům dotazů. V případě, že potřebujete mít stejná data D (například Prop_Info ve vašem případě) vrácené dvěma samostatnými dotazy na dvě samostatné kolekce A a B , musíte si vybrat z následujících tří strategií:

1. Duplicitní D v dokumentech obou A a B a vynutit konzistenci s vaším kódem. Toto je typicky návrhová volba vysoce výkonných systémů, které chtějí eliminovat potřebu druhého dotazu, i když to přichází za cenu dodatečné složitosti kódu na straně vložení/aktualizace a s některými potenciálními problémy s konzistencí, protože Mongo není ACID.

2. Vložte D v A a uložit odkaz (DBRef nebo nějakou jinou kombinaci identifikačních polí) v B abyste se k němu dostali druhým dotazem. Toto je obvykle volba designu, když počet dotazů na A překračuje počet dotazů na B . Zachovává D místní k častěji dotazované sbírce. V tomto vzoru návrhu schématu stačí vytvořit druhý dotaz, když zadáte dotaz B .

3. Vložte D v nové kolekci C a proveďte na něj druhý dotaz z obou A a B . Toto je obvykle návrhová volba tváří v tvář velmi nejistým budoucím požadavkům, kde není jasné, jaké by byly kompromisy, pokud byste zvolili (1) nebo (2) výše. Je to nejvíce "relační" schéma a to, které vás donutí provést druhý dotaz, když se dotazujete na obě A a B .

Jakou strategii zvolíte, závisí na vaší doméně, vzorcích dotazů, podpoře, kterou získáte od rámce objektově-relačního mapování (ORM) (pokud jej používáte), a v neposlední řadě na vašich preferencích.

V situacích, se kterými jsem se setkal, jsem si nikdy nevybral (3). Použil jsem (1) ve vysoce výkonných situacích (analytické systémy). Použil jsem (2) všude jinde, protože vzorce přístupu k dotazům jasně ukázaly, kde by měla „sdílená“ data žít.

Jakmile si vyberete strategii, pokud stále potřebujete pomoc, položte další otázku SO, která se konkrétně zaměřuje na problém návrhu schématu s ohledem na zvolenou strategii.

Tři tipy na závěr:

1. Pokud sdílená data D má násobnost vztahu větší než 1 použijte pole. Můžete indexovat celá pole a můžete se dotazovat přesně uvnitř polí pomocí $elemMatch .

2. Chcete-li aktualizovat D ve strategii (1) nebo (2) použijte atomový modifikátor MongoDB operace , z nichž mnohé jsou navrženy pro provoz na polích.

3. Tato otázka SO pokrývá vzor dvou dotazů DBRef v odpovědi @Stennie. (@Stennie pracuje pro 10gen, markery MongoDB.)

Hodně štěstí!