Projektowanie schematu MongoDB

Kiedy MongoDB został wprowadzony kilka lat temu, jedną z ważnych cech, które się chwalono, była możliwość bycia „bez schematu” – co to oznacza dla twoich dokumentów?

Projekt schematu MongoDB nie wymusza żadnego schematu w dokumentach przechowywanych w kolekcji. MongoDB zasadniczo przechowuje dokumenty JSON, a każdy dokument może zawierać dowolną strukturę. Rozważ kilka przykładów z naszej kolekcji „kontakty” poniżej. Oto jeden dokument, który możesz przechowywać:

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

Teraz drugi dokument przechowywany w kolekcji może mieć następujący format:

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

To całkiem fajne, że możesz przechowywać oba te dokumenty w tej samej kolekcji. Problem jednak zaczyna się, gdy trzeba odzyskać te dokumenty z kolekcji. Jak sprawdzić, czy pobrany dokument zawiera format 1 czy format 2? Możesz sprawdzić, czy pobrany dokument zawiera pole „ssn”, a następnie podjąć decyzję. Inną opcją jest zapisanie typu dokumentu w samym dokumencie:

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

W obu tych przypadkach udało się przenieść wymuszanie schematu z bazy danych do aplikacji -

Zawsze istnieje schemat, chodzi tylko o to, gdzie jest zaimplementowany.

Jeśli masz odpowiednie indeksy, w pewnym stopniu łagodzi to problem. Jeśli większość zapytań dotyczy „identyfikatora pracownika”, wiesz, że pobrany dokument ma zawsze drugi format – jednak reszta kodu, który nie korzysta z tego indeksu, nadal będzie miała wspomniany powyżej problem. Ponadto, jeśli używasz ODM, takiego jak mangusta, automatycznie wymusza on dla ciebie schemat na górze MongoDB.

Istnieje kilka aplikacji, które korzystają z tej elastyczności. Jednym ze scenariuszy, który przychodzi mi do głowy, jest przypadek schematu, w którym istnieje wiele opcjonalnych pól/kolumn. W MongoDB nie ma kary za brakujące kolumny. Każdy dokument może zawierać tylko te pola, których potrzebuje.

Weryfikacja dokumentów

Począwszy od wersji 3.2.x MongoDB obsługuje teraz koncepcję walidacji schematu przy użyciu konstrukcji „validator”. Zapewnia to wiele poziomów walidacji – dzięki czemu możesz wybrać poziom, który Ci odpowiada. Domyślnym zachowaniem, jeśli nie używasz walidatora, jest poprzednie zachowanie bez schematu. Zazwyczaj „walidatory” tworzy się w momencie tworzenia kolekcji

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

Istniejące kolekcje

Istniejące kolekcje można zaktualizować za pomocą polecenia „collMod”:

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

Poziom walidacji

MongoDB obsługuje koncepcję „ValidationLevel”. Domyślny poziom walidacji to „ścisły”, co oznacza, że ​​wstawianie i aktualizowanie kończy się niepowodzeniem, jeśli dokument nie spełnia kryteriów walidacji. Jeśli poziom walidacji to „Umiarkowany”, walidację stosuje się do istniejących dokumentów, które spełniają kryteria walidacji. Dokumenty, które obecnie istnieją i nie spełniają kryteriów, nie są weryfikowane. Chociaż jest to wygodne, poziom walidacji „Umiarkowany” może narazić Cię na kłopoty – dlatego należy go używać ostrożnie.

Akcja weryfikacji

Domyślnie działaniem walidacji jest „Błąd”. Jeśli dokument nie przejdzie weryfikacji, oznacza to błąd i aktualizacja/wstawienie nie powiedzie się. Możesz jednak ustawić akcję Walidacja na „ostrzeż”, która zasadniczo rejestruje naruszenie schematu w dzienniku, ale nie powoduje niepowodzenia wstawienia.

Jakie przykłady projektów schematów pomogą Ci w następnym projekcie, daj nam znać!