MongoDB: Introduction to Data Models

The data in MongoDB has a flexible pattern. Unlike SQL databases, which require that you have to decide and declare a table's schema before inserting data, the MongoDB collection does not enforce the structure of the document. This flexibility facilitates mapping of documents to entities or objects. Each document can match the data field of the entity you want to represent, even if the data changes significantly. In practice, however, a collection of documents shares a similar structure.

The key challenge of the data model is to balance the needs of the application, the performance of the database engine, and the data access pattern. When designing a data model, consider the use of data in the application (e.g., querying, updating, and processing data), as well as the intrinsic structure of the data itself.

Document structure

The key to designing a data model for MONGODB applications is how the structure and application of the document represent the connection between the data. There are two tools to allow the app to represent these relationships: referencing and embedding the document (references and embedded documents).

• Reference

References store relationships between data through references that include a connection or a document to another document. Applications can parse these references to access relevant data. Broadly speaking, these are normalized data models (normalized. models).

The data model uses references to contact the document. Contract Documents and access documents protect references to user documents.

The advantages and disadvantages of the normalized data model using references are described below:

The normalization model uses references to describe the relationships between documents. Generally, the normalization model is used,

1. Embedding results in data duplication and does not provide effective read performance.
2. Represents a more complex, many-to-many relationship
3. Modeling large Hierarchical data

References are more flexible than embedded documents. However, the client app must handle the query problems that the reference brings. In summary, the normalized data model requires more round-trips to the server.

• Embed data

Embedded documents capture the relationship between data by storing relevant data in a single document structure. MongoDB documents allow a field or field data in a document to embed a document as a subdocument-specific possibility. These denormalized data enable applications to acquire and manipulate data in a single database Operation force.

Data model is the embedded field to protect all relevant information.

The pros and cons of the data model for embedding sub-documents are discussed below:

With MongoDB, you can embed related data in a single structure or document. This model is a well-known "denormalized" model that leverages the benefits of MongoDB's rich documentation.

The embedded data model allows applications to store relevant fragment information in the same database record. Therefore, when the application completes a normal operation, it only needs to handle a few queries or updates.

In general, you can use the embedded data model when the following scenario:

1. There are "containment relationships" between entities
2. There is a one-to-many relationship between entities. In these relationships, "many" or sub-documents are often seen as "one" or in the context of the parent document

In general, embedding provides better read performance and the ability to request and obtain relevant data in a single database operation. The embedded data model makes it possible to update related data in which atomic operations.

However, embedding the data model in a document can cause the document to grow after it is created. Document growth can affect write performance and result in data fragmentation issues. Also, the document size in MongoDB must be less than the maximum Bson document size. For large binary data, consider Gridfs.

Atomic nature of write operations

In MongoDB, write operations are atomic at the level of the document, and there is no single write operation that can atomically affect multiple documents or collections. A non-normalized data model with embedded data contains related data that can represent an entity in a single document. This facilitates the atomicity of the write operation, because a single write operation can insert or update data directly to an entity. Normalized data disperses data across multiple collections, which requires multiple writes and is therefore not atomic.

However, a pattern that favors atomic writing restricts the way that an application uses data or modifies data. It is therefore necessary to balance atomicity and balance.

Document growth

Some updates, such as adding elements to an array or adding new fields, increase the size of the document. If the size of the document exceeds the space allotted to the document, MongoDB repositions the document. The growth of the document affects the selection of normalized and denormalized data.

Data usage and performance

When designing a document model, consider how the app will use your database. For example, if your app uses only recently inserted data, consider using Capped collections. Or, your app needs to always read, adding indexes is a common way to improve performance.