sql >> Databáze >  >> NoSQL >> MongoDB

Návrh schématu MongoDB:Vždy existuje schéma

Návrh schématu MongoDB

Když byl MongoDB před několika lety představen, jednou z důležitých funkcí byla schopnost „bez schématu“ – Co to znamená pro vaše dokumenty?

Návrh schématu MongoDB nevynucuje u dokumentů uložených v kolekci žádné schéma. MongoDB v podstatě ukládá dokumenty JSON a každý dokument může obsahovat libovolnou strukturu, kterou chcete. Zvažte některé příklady z naší sbírky „kontaktů“ níže. Zde je jeden dokument, který můžete uložit:

{
  'name':'user1',
  'address':' 1 mountain view',
  'phone': '123-324-3308',
  'SSN':'123-45-7891'
}

Nyní může mít druhý dokument uložený ve sbírce tento formát:

{
  'name': ' user2',
  'employeeid': 546789
}

Je skvělé, že oba tyto dokumenty můžete uložit do stejné sbírky. Problém však nastává ve chvíli, kdy potřebujete tyto dokumenty z fondu získat. Jak zjistíte, zda načtený dokument obsahuje formát 1 nebo formát 2? Můžete zkontrolovat, zda načtený dokument obsahuje pole „ssn“, a poté se rozhodnout. Další možností je uložit typ dokumentu do samotného dokumentu:

{
  'type': xxx,
  'name': ....
  ...
}

V obou těchto případech jste dosáhli přesunutí vynucení schématu z databáze do aplikace -

Schéma existuje vždy, jde jen o to, kde je implementováno.

Pokud máte správné indexy, problém do určité míry zmírňuje. Pokud je většina vašich dotazů na ‚id zaměstnance‘, víte, že načtený dokument je vždy druhého formátu – nicméně zbytek vašeho kódu, který nepoužívá tento index, bude mít stále výše zmíněný problém. Také pokud používáte ODM, jako je mongoose, pak pro vás automaticky již vynucuje schéma nad MongoDB.

Existuje několik aplikací, které těží z této flexibility. Jeden scénář, který přichází na mysl, je případ schématu, kde existuje řada volitelných polí/sloupců. V MongoDB neexistuje žádný postih za chybějící sloupce. Každý dokument může obsahovat pouze pole, která potřebuje.

Ověření dokumentu

Počínaje verzí 3.2.x MongoDB nyní podporuje koncept ověřování schématu pomocí konstrukce „validator“. To poskytuje mnoho úrovní ověření – takže si můžete vybrat úroveň, která vám vyhovuje. Výchozí chování, pokud nepoužíváte validátor, je předchozí chování bez schématu. Obvykle vytvoříte „validátory“ při vytváření kolekce

db.createCollection( "contacts",
   { validator: { $or:
      [
         { employeeid: { $exists: true }},
         { SSN: { $exists: true } }
      ]
   }
} )
Vytvořte ověření schématu v MongoDB, abyste si mohli vybrat úroveň, kterou potřebujeteClick To Tweet

Stávající sbírky

Stávající kolekce lze aktualizovat pomocí příkazu ‚collMod‘:

db.runCommand( {
  collMod: "contacts”,
  validator: { $or: [ { employeeid: { $exists: true }}, { SSN: { $exists:true} } ] }
} )

Úroveň ověření

MongoDB podporuje koncept ‚ValidationLevel‘. Výchozí úroveň ověření je „přísná“, což znamená, že vložení a aktualizace selžou, pokud dokument nesplňuje kritéria ověření. Pokud je úroveň ověření „střední“, použije se ověření na existující dokumenty, které splňují kritéria ověření. Dokumenty, které aktuálně existují a nesplňují kritéria, nejsou ověřeny. Úroveň ověření „Střední“ je sice pohodlná, ale může vás dostat do problémů – proto je třeba ji používat opatrně.

Ověřovací akce

Ve výchozím nastavení je akce ověření „Chyba“. Pokud se ověření vašeho dokumentu nezdaří, jedná se o chybu a aktualizace/vložení se nezdaří. Můžete však také nastavit akci Ověření na ‚upozornění‘, která v podstatě zaznamená porušení schématu do protokolu, ale vložení se nezdaří.

Jaké příklady návrhu schémat by vám pomohly na vašem dalším projektu, dejte nám vědět!


  1. Snížení velikosti souboru databáze MongoDB

  2. Redis:Amazon EC2 vs Elasticache

  3. Pět tipů pro lepší hosting MongoDB v Azure

  4. NestJS:Jak implementovat autentizaci uživatele na základě relace