MongoDB: Introduction to Data Models

The data in MongoDB has a flexible pattern. Unlike SQL database, (SQL database) requires that you have to decide and declare a table's schema before inserting the data. The collection of MongoDB 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 very 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 usage of the data in the application (e.g.. Query, update, and process data), as well as the intrinsic structure of the data itself.

Document structure

The key to designing a data model for MongoDB applications is to surround the structure of the document and how it is used to represent the connection between the data. There are two tools to agree with the app to represent these relationships: referencing and embedding documents (references and embedded document).

• Reference

A reference stores the relationship between data by including a connection or a document to a reference between the documents. 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 normalized model uses reference descriptions to describe the relationship between documents. In general. There are cases where the normalized model is used.

1. When embedding causes data to be repeated 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. But the client app must handle the query problems that the reference brings. In summary, a normalized data model requires many other round-trip servers.

• 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 detail possibility. These denormalized data enable applications to acquire and manipulate data in a single database Operation force.

Data model is the embedded field protection of all relevant information.

The following discusses the pros and cons of data models that embed sub-documents:

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 agrees that the application stores the relevant fragment information in the same database record.

So. When the application finishes a normal operation, it only needs to handle very few queries or updates.

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

1. There are "include 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 a 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 includes relevant 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. So it's not atomic.

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

Document growth

Some updates, adding elements to an array of directions or adding new fields, will increase the size of the document.

If the size of the document exceeds the space allotted to the document, MongoDB will locate the document again. 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 application will use your database. Example. Suppose 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.

MongoDB: Introduction to Data Models