"Monogdb" MongoDB's Top ten application design skills

skill One, the tradeoff between speed and completeness

The data used in multiple documents can be in either inline (inverse paradigm) or in a reference (normalized) manner. This strategy does not have the merits and demerits, each has the pros and cons. The key is to choose the scenario scenario that suits you. Inverse normalization results in inconsistent data. However, if it is normalized, the application must make an additional search at each confirmation. Because high performance and instantaneous consistency cannot be combined, it is important to understand which application is most needed.

Considerations typically include:

Is there always an extra reading of data that is barely changed?

Is consistency important?

Do you want to read it quickly?

second, to adapt to the future of the data to be normalizednormalization can make data more usable for a longer time, and in the future it can query the normalized data in different ways in various applications. The premise here is that some data will be used by various applications for a year to come.
tip Three, try to get the data as a single queryMongoDB Database design should be based on the query of the application unit. application Unit for Web apps or mobile apps that can treat a single request to the backend as an application unitfor desktop applications, a single user interaction can be considered an application unitfor the analysis system, the load of a chart is counted as an application unittechnique Iv. embedding associated datawhen you are hesitant about embedding and referencing documents, don't think about the purpose of the query to get the fields themselves or to get more extensive information. If the former suggests embedding associative data. technique Five, embedding time-point dataFor example, if someone updates their personal information, they don't need to change their previous order content .Tip Six, don't embed ever-increasing dataThe mechanism by which MongoDB stores data determines that data is continuously appended to data that is inefficient. The size of the data and objects should be relatively fixed in normal use. Tip Seven, pre-populated dataIf you already know which fields to use in the future, the first time you insert them is more efficient than creating them. For example, to use new collections every day, it is best to create them in advance. skill Eight, allocating space as much as possibleYou can use this optimization method as long as you know that the document is starting to be small and will later become a definite size. The first time you insert a document, it is populated with the same garbage data as the final data size. That is, add a garbage field (which contains a string that is the same size as the Final Document)tip Nine, use arrays to store embedded data for anonymous accessA common question is whether the embedded information is either European or NI data or stored in a document. If you know exactly what the query is, use the subdocument to save it. If you do not know the exact content of the query at times, you want to array. The array is usually used when you know the query criteria for some entries. Tip Ten: Document to be self-sufficient

MongoDB is a large, brain-free data store. MongoDB hardly does any data processing, just stores the information. Try to keep this in mind and avoid having mongodb do some calculations that can be done on the client side. Even writing small tasks, like averaging or summing, should be done on the client side.

If the information you are looking for must be calculated and cannot be obtained directly from the document, there are two definitions:
Pay high performance costs and optimize the document structure so that the information can be obtained directly from the document.

"Monogdb" MongoDB's Top ten application design skills