Моделирование данных MongoDB

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

Дизайн модели данных

MongoDB предоставляет два типа моделей данных: встроенную модель данных и нормализованную модель данных. В зависимости от требований, вы можете использовать任何一个 из этих моделей при подготовке документов.

Вложенная модель данных

В этой модели все связанные данные (вложенные) можно поместить в один документ, что также называется не нормализованной моделью данных.

Например, предположим, что мы получаем подробности сотрудника из трех различных документов (Personal_details, Contact и Address). Тогда все три документа можно嵌入 в один документ, как показано ниже:

{
	_id:,
	Emp_ID: "10025AE336"
	Personal_details:{
		First_Name: "Radhika"
		Last_Name: "Sharma"
		Date_Of_Birth: "1995-09-26"
	},
	Контакт: {
		e-mail: "[email protected]"
		телефон: "9848022338"
	},
	Адрес: {
		city: "Hyderabad",
		Area: "Madapur",
		State: "Telangana"
	}
}

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

В этой модели вы можете использовать ссылки для ссылки на поддокументы в исходных документах. Например, вы можете переписать следующий документ в нормализованной модели:

Employee:

{
	_id: ObjectId101>
	Emp_ID: "10025AE336"
}

Personal_details:

{
	_id: ObjectId102>
	empDocID: "ObjectId101"
	First_Name: "Radhika"
	Last_Name: "Sharma"
	Date_Of_Birth: "1995-09-26"
}

Контакт:

{
	_id: ObjectId103>
	empDocID: "ObjectId101"
	e-mail: "[email protected]"
	телефон: "9848022338"
}

Адрес:

{
	_id: ObjectId104>
	empDocID: "ObjectId101"
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

Внимания при проектировании архитектуры в MongoDB

• Дизайн архитектуры по запросу пользователя.

• Если их использовать вместе, объедините их в один документ. В противном случае, разделите их (но убедитесь, что их не нужно соединять).

• Копируйте данные (но с ограничениями), так как место на диске дешевле времени вычислений.

• Соединяйте данные при записи, а не при чтении.

• Оптимизируйте свою схему для наиболее распространенных сценариев использования.

• В архитектуре выполняются сложные агрегации.

Онлайн пример

Предположим, что клиент нуждается в дизайне базы данных для своего блога/сайта и хочет увидеть различия между дизайном RDBMS и MongoDB. У веб-сайта следующие требования.

• У каждой темы есть уникальный заголовок, описание и адрес.

• Каждая тема может иметь один или несколько тегов.

• У каждой темы есть имя автора и общее количество лайков.

• Каждая тема содержит комментарии пользователей, их имена, сообщения, дату и время публикации и лайки.

• На каждом посте может быть ноль или несколько комментариев.

В архитектуре RDBMS, дизайн для вышеуказанных требований будет иметь как минимум три таблицы.

В модели MongoDB, дизайн будет иметь одну коллекцию постов и следующую структуру-

{
　　　_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
　　　　　　}
　　　]
}

Таким образом, при отображении данных в RDBMS, вам нужно связать три таблицы, а в MongoDB данные будут отображаться только из одной коллекции.