Предыдущая часть: “MongoDB: введение, преимущества и настройка среды

Данные в MongoDB обладают гибкой схемой хранения документов в одной коллекции. Документам не обязательно иметь одинаковый набор полей или структуру. Общие поля в них могут содержать разные типы данных. 

Типы моделей данных

MongoDB предоставляет два типа моделей данных: встроенную и нормализованную. В зависимости от требований допускается применение любой из моделей при подготовке документа.

Встроенная модель данных 

Данная модель, еще известная как денормализованная, позволяет встраивать все связанные данные в один документ. 

Предположим, мы получаем данные о сотрудниках в трех разных документах: Personal_details, Contact и Address. Встроим все три документа в один, как показано ниже: 

{
_id: ,
Emp_ID: "2C325A33F6"
Personal_details:{
First_Name: "Ivan",
Last_Name: "Ivanov",
Date_Of_Birth: "1980-01-01"
},
Contact: {
e-mail: "[email protected]",
phone: "9098022338"
},
Address: {
city: "Moscow",
country: "Russia"
}
}

Нормализованная модель данных 

Данная модель позволяет обращаться к поддокументам в исходном документе, используя ссылки. Перепишем ранее рассмотренный документ согласно нормализованной модели: 

Employee:

{
_id: <ObjectId101>,
Emp_ID: "2C325A33F6"
}

Personal_details:

{
_id: <ObjectId102>,
empDocID: " ObjectId101",
First_Name: "Ivan",
Last_Name: "Ivanov",
Date_Of_Birth: "1980-01-01"
}

Contact:

{
_id: <ObjectId103>,
empDocID: " ObjectId101",
e-mail: "[email protected]",
phone: "9098022338"
}

Address:

{
_id: <ObjectId104>,
empDocID: " ObjectId101",
city: "Moscow",
country: "Russia"
}

Рекомендации при проектировании схемы в MongoDB

  • Проектируйте схему в соответствии с требованиями пользователя. 
  • Если вы планируете использовать объекты вместе, объедините их в один документ. В противном случае разъедините их, но прежде убедитесь, что необходимость в соединении отсутствует. 
  • Дублируйте данные (умеренно), поскольку пространство на диске дешевле, чем время вычисления. 
  • Выполняйте операции соединения при написании, а не при чтении. 
  • Оптимизируйте схему для наиболее частых случаев использования. 
  • Выполняйте сложные операции агрегации в схеме. 

Пример

Допустим, нужно создать проект базы данных для блога/веб-сайта клиента и показать ему отличия между схемами РСУБД и MongoDB. К каждой публикации на сайте предъявляются следующие требования. Она должна: 

  • обладать уникальным заголовком, описанием и url;
  • иметь один или два тега;
  • сопровождаться упоминанием имени ее автора и общим количеством лайков;
  • иметь комментарии пользователей с их именами, сообщениями, лайками, указанием даты и времени; 
  • иметь несколько комментариев или ни одного. 

Учитывая данные требования, в схеме РСУБД проект будет состоять, как минимум, из 3 таблиц: 

А в схеме MongoDB он будет включать одну коллекцию Post и следующую структуру: 

{
_id: POST_ID
title: TITLE_OF_POST,
description: POST_DESCRIPTION,
by: POST_BY,
url: URL_OF_POST,
tags: [TAG1, TAG2, TAG3],
likes: TOTAL_LIKES,
comments: [
{
user:'COMMENT_BY',
message: TEXT,
dateCreated: DATE_TIME,
like: LIKES
},
{
user:'COMMENT_BY',
message: TEXT,
dateCreated: DATE_TIME,
like: LIKES
}
]
}

Таким образом, для показа данных в РСУБД потребуется объединить три таблицы, тогда как в MongoDB данные будут отображаться только из одной коллекции.

Читайте также:

Читайте нас в TelegramVK и Яндекс.Дзен

Предыдущая статьяНовый модуль временных рядов PyCaret
Следующая статьяMongoDB: создание базы данных