Дизайн на схема на MongoDB

Когато MongoDB беше представена преди няколко години, една от важните функции, които се рекламираха, беше възможността да бъдете „безсхемни“ – Какво означава това за вашите документи?

Дизайнът на схема на MongoDB не налага никаква схема върху документите, съхранявани в колекция. MongoDB по същество съхранява JSON документи и всеки документ може да съдържа всяка структура, която искате. Разгледайте някои примери от нашата колекция „контакти“ по-долу. Ето един документ, който можете да съхранявате:

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

Сега вторият документ, съхранен в колекцията, може да бъде в този формат:

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

Доста е страхотно, че можете да съхранявате и двата документа в една и съща колекция. Проблемът обаче започва, когато трябва да извлечете тези документи от колекцията. Как да разберете дали извлеченият документ съдържа формат 1 или формат 2? Можете да проверите дали извлеченият документ съдържа полето „ssn“ и след това да вземете решение. Друга възможност е да съхраните типа на документа в самия документ:

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

И в двата случая това, което сте постигнали, е преместване на прилагането на схемата от базата данни към приложението -

Винаги има схема, въпросът е само къде е внедрена.

Ако имате правилните индекси, това облекчава проблема до известна степен. Ако по-голямата част от вашите заявки са от „employeeid“, вие знаете, че извлеченият документ винаги е от втория формат – обаче останалата част от вашия код, която не използва този индекс, все още ще има споменатия по-горе проблем. Също така, ако използвате ODM като mongoose, той автоматично вече налага схема за вас върху MongoDB.

Има няколко приложения, които се възползват от тази гъвкавост. Един сценарий, който идва на ум, е случаят на схема, където има редица незадължителни полета/колони. В MongoDB няма наказание за липсващи колони. Всеки документ може да съдържа само полетата, които са му необходими.

Проверка на документ

Стартирането на версия 3.2.x MongoDB вече поддържа концепцията за валидиране на схемата с помощта на конструкцията „валидатор“. Това осигурява много нива на валидиране – така че можете да изберете нивото, което работи за вас. Поведението по подразбиране, ако не използвате валидатор, е предишното поведение без схема. Обикновено ще създавате „валидаторите“ по време на създаването на колекция

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

Съществуващи колекции

Съществуващите колекции могат да бъдат актуализирани с помощта на командата ‘collMod’:

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

Ниво на валидиране

MongoDB поддържа концепцията за „ValidationLevel“. Нивото на валидиране по подразбиране е „строго“, което означава, че вмъкванията и актуализациите се провалят, ако документът не отговаря на критериите за валидиране. Ако нивото на валидиране е „Умерено“, то прилага валидирането към съществуващи документи, които отговарят на критериите за валидиране. Документи, които съществуват в момента и не отговарят на критериите, не се валидират. Макар и удобно, нивото на валидиране „Умерено“ може да ви създаде проблеми в бъдеще – така че трябва да се използва внимателно.

Действие за проверка

По подразбиране действието за валидиране е „Грешка“. Ако вашият документ не успее да бъде валидиран, това е грешка и актуализирането/вмъкването е неуспешно. Можете обаче също да настроите действието за валидиране на „предупреждение“, което основно регистрира нарушението на схемата в дневника, но не проваля вмъкването.

Какви примери за дизайн на схеми ще ви помогнат при следващия ви проект, уведомете ни!