Spring Data Mongo - použijte jedinečná kombinační pole ve vloženém dokumentu

V MongoDB jedinečný index zajišťuje, že konkrétní hodnota v poli není přítomna ve více než jednom dokumentu. nebude zaručit, že hodnota je jedinečná v rámci pole v rámci jednoho dokumentu. To je vysvětleno zde v Manuálu MongoDB, kde pojednává o jedinečných víceklíčových indexech.

Jedinečný index tedy nesplní váš požadavek. Zabrání tomu, aby samostatné dokumenty obsahovaly duplicitní kombinace, ale stále umožní, aby jeden dokument obsahoval duplicitní hodnoty v poli.

Nejlepší možností, kterou máte, je změnit svůj datový model tak, aby se pole objektů technologyEmployeeRef rozdělilo do samostatných dokumentů. Rozdělení na samostatné dokumenty vám umožní použít jedinečný index k vynucení jedinečnosti.

Konkrétní implementace, která by měla být použita pro tuto změnu datového modelu, by závisela na vašem vzoru přístupu (což je mimo rozsah této otázky).

Jedním ze způsobů, jak toho dosáhnout, je vytvořit kolekci TechnologyEmployee, která obsahuje všechna pole, která aktuálně existují v poli technologyEmployeeRef. Kromě toho by tato kolekce TechnologyEmployee měla pole, jako je e-mail, které by vám umožnilo přidružit ji k dokumentu v kolekci Employee.

Vzorový zaměstnanecký dokument

{
  ....
  ....
  "firstName" : "John",
  "lastName" : "Doe",
  "email" : "[email protected]",
  .....
  .....
  .....
}

Vzorový dokument zaměstnanecké technologie

{
  "email" : "[email protected]",
  "technologyCd" : "Java",
  "technologyName" : "Java8",
  ....
  .....
  "status" : "A"
}

Index ve sbírce EmployeeTechnology

{'email' : 1, 'technologyCd' : 1}, {unique: true}

Nevýhodou tohoto přístupu je, že byste museli číst ze dvou kolekcí, abyste měli všechna data. Tato nevýhoda nemusí být velkým problémem, pokud zřídka potřebujete načíst data z obou kolekcí současně. Pokud potřebujete všechna data, lze je urychlit pomocí indexů. S indexy by to mohlo být urychleno pomocí skrytých dotazů.

Další možností je denormalizace dat. Udělali byste to tak, že byste duplikovali data zaměstnance, ke kterým potřebujete mít přístup ve stejnou dobu jako data technologie.

Vzorové dokumenty

[
  {
    ....
    "firstName" : "John",
    "lastName" : "Doe",
    "email" : "[email protected]",
    .....
    "technologyCd" : "Java",
    "technologyName" : "Java8",
    ....
    "status" : "A"
  },
  {
    ....
    "firstName" : "John",
    "lastName" : "Doe",
    "email" : "[email protected]",
    .....
    "technologyCd" : "Spring",
    "technologyName" : "Spring Boot2",
    ....
    "status" : "A"
  }
]

V tomto příspěvku na blogu MongoDB říkají, že

Udělali byste to pouze pro pole, která se často čtou, čtou se mnohem častěji, než se aktualizují, a kde nevyžadujete silnou konzistenci, protože aktualizace denormalizované hodnoty je pomalejší, dražší a není atomická.

Nebo jak jste již uvedli, může mít smysl ponechat datový model tak, jak je, a provést kontrolu jedinečnosti na straně aplikace. To vám pravděpodobně poskytne nejlepší výkon při čtení, ale přináší to určité nevýhody. Za prvé, zpomalí operace zápisu, protože aplikace bude muset provést nějaké kontroly, než bude moci aktualizovat databázi.

Může to být nepravděpodobné, ale existuje také možnost, že byste mohli skončit s duplikáty. Pokud existují dva požadavky na vložení stejného objektu EmployeeTechnology do pole, může ověření druhého požadavku skončit (a projít) dříve, než se první požadavek zapíše do databáze. Sám jsem viděl podobný scénář s aplikací, na které jsem pracoval. Přestože aplikace kontrolovala jedinečnost, pokud uživatel poklepal na tlačítko Odeslat, skončilo by to jako duplicitní záznamy v databázi. V tomto případě deaktivace tlačítka při prvním kliknutí drasticky snížila riziko. Toto malé riziko může být tolerovatelné v závislosti na vašich požadavcích a dopadu duplicitních záznamů.

Který přístup dává největší smysl, do značné míry závisí na vašem vzoru přístupu a požadavcích. Doufám, že to pomůže.