MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

Преглед на валидирането на схемата на MongoDB

Всеки знае, че MongoDB е без схема, тогава защо се изисква да се извършва валидиране на схема? Лесно и бързо е да се разработи приложението с поведението без схема на MongoDB и да се използва като доказателство за концепция. Но след като приложението премине към производство и стане стабилно и зряло, няма нужда да променяте често схемата и също не е препоръчително. Понастоящем е много важно да наложите някаква валидация на схемата във вашата база данни, за да избегнете вмъкването на нежелани данни, които могат да нарушат приложението ви. Това става много по-важно, когато в една и съща база данни се вмъкват данни от множество източници.

Валидирането на схема ви позволява да дефинирате специфичната структура на документите във всяка колекция. Ако някой се опита да вмъкне някои документи, които не съвпадат с дефинираната схема, MongoDB може да отхвърли този вид операция или да даде предупреждения според типа на действието за валидиране.

MongoDB предоставя два начина за валидиране на вашата схема, валидиране на документ и валидиране на JSON схема. Проверката на JSON схема е разширената версия на валидирането на документи, така че нека започнем с валидирането на документи.

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

Повечето от разработчиците, които са работили с релационни бази данни, знаят важността на предвидимостта на моделите на данни или схемата. Следователно MongoDB въведе валидиране на документи от версия 3.2. Нека видим как да добавим правила за валидиране в колекциите на MongoDB.

Да предположим, че имате колекция от потребители, които имат следните типове документи.

{
    "name": "Alex",
    "email": "[email protected]",
    "mobile": "123-456-7890"
} 

И по-долу са валидациите, които искаме да проверим, докато добавяме нови документи в колекцията на потребителите:

  • полетата за име, имейл са задължителни
  • мобилните номера трябва да следват конкретна структура:xxx-xxx-xxxx

За да добавим тази валидация, можем да използваме конструкцията „валидатор“, докато създаваме нова колекция. Изпълнете следната заявка в обвивка Mongo,

db.createCollection("users", {
  validator: {
        $and: [
            {
                "name": {$type: "string", $exists: true}
            },
            {
                "mobile": {$type: "string", $regex: /^[0-9]{3}-[0-9]{3}-[0-9]{4}$/}
            },
            {
                "email": {$type: "string", $exists: true}
            }
        ]
    }
})

Трябва да видите следния изход:

{ "ok" : 1 }

Сега, ако се опитате да добавите нов документ, без да следвате правилата за валидиране, тогава mongo ще изведе грешка при валидиране. Опитайте да изпълните следните заявки за вмъкване.

Заявка:1

db.users.insert({
    "name": "akash"
})

Изход:

WriteResult({
    "nInserted" : 0,
    "writeError" : {
        "code" : 121,
        "errmsg" : "Document failed validation"
    }
})

Запитване:2

db.users.insert({
    "name": "akash",
    "email": "[email protected]",
    "mobile": "123-456-7890"
})

Изход:

WriteResult({ "nInserted" : 1 })

Въпреки това, има някои ограничения с подхода за валидиране на документи, като например човек може да добави произволен брой нови двойки ключ-стойност към документа и да го вмъкне в колекцията. Това не може да бъде предотвратено чрез валидиране на документ. Помислете за следния пример,

db.users.insert({
    "name": "akash",
    "email": "[email protected]",
    "mobile": "123-456-7890",
    "gender": "Male"
})

Изход:

WriteResult({ "nInserted" : 1 })

Освен това валидирането на документ проверява само стойностите. Да предположим, че ако се опитате да добавите документа с "nmae"(typo) като ключ вместо "name", mongo ще го счита за ново поле и документът ще бъде вмъкнат в DB. Тези неща трябва да се избягват, когато работите с производствената база данни. За да поддържа всичко това, MongoDB въведе оператора "jsonSchema" с конструкция "validator" от версия 3.6. Нека видим как да добавим същите правила за валидиране както по-горе и да избегнем добавянето на нови/грешно написани полета.

Severalnines Станете DBA на MongoDB – Пренасяне на MongoDB в Производството Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате MongoDB Изтеглете безплатно

Проверка на jsonSchema

Изпълнете следната команда в mongo shell, за да добавите правилата за валидиране с помощта на оператор „jsonSchema“.

db.runCommand(
  {
    "collMod": "users_temp",
    "validator": {
      "$jsonSchema": {
        "bsonType": "object",
        "additionalProperties": false,
        "required": [
          "name",
          "email"
        ],
        "properties": {
          "_id": {},
          "name": {
            "bsonType": "string"
          },
          "email": {
            "bsonType": "string"
          },
          "mobile": {
            "bsonType": "string",
            "pattern": "^[0-9]{3}-[0-9]{3}-[0-9]{4}$"
          }
        }
      }
    }
  })

Нека видим сега какво се случва, когато се опитаме да вмъкнем следния документ.

db.users.insert({
    "name": "akash",
    "email": "[email protected]",
    "mobile": "123-456-7890",
    "gender": "Male"
})

Ще изведе грешка, тъй като не сме дефинирали полето за пол в „jsonSchema“.

WriteResult({
    "nInserted" : 0,
    "writeError" : {
        "code" : 121,
        "errmsg" : "Document failed validation"
    }
})

По същия начин, ако имате правописни грешки в имена на полета, mongo ще изведе същата грешка.

Схемата, дефинирана по-горе, е същата като тази, която използвахме при валидирането на документи. Освен това добавихме полето „additionalProperties“, за да избегнем печатни грешки в имената на полета и добавянето на нови полета в документите. Той ще позволи само полета, които са дефинирани в полето "свойства". Ето преглед на някои свойства, които можем да използваме под оператор "jsonSchema".

  • bsonType:масив | обект | низ | булева | номер | нула
  • задължително:масив от всички задължителни полета
  • enum:масив само от възможни стойности за всяко поле
  • минимална:минимална стойност на полето
  • максимум:максимална стойност на полето
  • minLength:минимална дължина на полето
  • mixLength:максимална дължина на полето
  • свойства:колекция от валидни JSON схеми
  • additionalProperties:спира ни да добавяме други полета, освен посочени в полето за свойства
  • заглавие:заглавие за всяко поле.
  • описание:кратко описание за всяко поле.

Освен проверката на схемата, операторът "jsonSchema" може да се използва и в етапа на намиране и съответствие в конвейера за агрегиране.

Заключение

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

В тази статия научихме за важността на валидирането на схемата в MongoDB и как да добавяме валидации на ниво документ с помощта на валидиране на документ и оператор „jsonSchema“.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. $project:Възможно ли е достъп до свойство на резултат от израз само на един етап?

  2. Намерете документи с масив, който не съдържа конкретна стойност

  3. Върнете последния документ от справка

  4. Как мога да създам програма с помощта на c++ драйвер на mongodb?

  5. Преобразувайте ObjectID (Mongodb) в String в JavaScript