MongoDB Data Model

The data in MongoDB has a flexible pattern. Unlike SQL database, you must determine the pattern before inserting the data and declaring a table,

the collection of MongoDB does not execute the document structure. He has the flexibility to conveniently map files to an entity or object. Each document can match the entity represented by the data field,

even if the data is materially changed. In practice, however, the files in the collection share a similar structure. The key challenge in data modeling is balancing applications

Needs, the performance characteristics of the database engine, the data retrieval mode. When you design a data model, you always consider the data that your application uses (such as queries, updates, and

data) and the structure inherent in the information itself.

Document Structure

The key determinant of the data model design for MONGODB applications is the relationship between the structure of the document and the application's representation of the data. There are two

A tool that allows applications to represent these relationships: referenced and embedded documents.

References

Reference references store relational data, including links or references moved from one document to another. Applications can resolve these reference access related numbers

According to Broadly speaking, these are normalized data models that describe the relationship between using referenced documents. ）

Conditions of Use: (1) When readability is more advantageous than when data repeats (2) represents a complex many-to-many relationship when (3) large hierarchical datasets are modeled.

embedded type
The embedded storage-related data captures the relationship between the data files in a document structure. A MongoDB document can embed a subdocument field in a document structure

in a document or an array. These denormalized data models allow applications to retrieve and manipulate related data in a single database operation. Simply put

is: MongoDB, you can embed related data into a structure or document. These patterns are often referred to as "informal" models and utilize MongoDB's abundance

The rich documentation. Regardless of the table structure, the embedded data model allows application-related information to be stored in the same database record. As a result, the application

You may need to complete fewer queries and updates for common operational issues. Such as:

Conditions of Use (1) one-to-one relationship model (2) one-to-many relationship model

In general, embedding provides better performance for read operations, as well as the ability to request and retrieve related data in a single database operation. The embedded data model can

Enough to update the relevant data in a single atomic write operation. However, embedding related data in a document can lead to growth after file creation. Document growth

Can affect the impact of write performance, resulting in data fragmentation. In addition, the MongoDB document must be less than the maximum Bson document size. For most of your binary data, consider

Gridfs.

Atomic nature of write operations

Write operations at the MongoDB document level are atomic, and no one write operation can automatically affect multiple documents or multiple collections. Normalized data model and nested

The incoming data combines all the relevant data represented by the entity in one document. This helps the atomic write operation from a write operation to insert or update the data in real

Body. However, the atoms of a write operation may limit how the application can use the data, or it may limit the way the application is modified.

data usage and performance
If the requirements of an application are primarily a collection of read operations, adding indexes to support common queries can improve performance.

MongoDB Data Model