"Reprint" on MongoDB's application scenario

Reference: http://blog.csdn.net/adparking/article/details/38727911

MongoDB's application in the online search, very little about the traditional application of information on how to use MongoDB database content, more or to introduce the log collection and storage, small files distributed storage, similar to the Internet microblogging application data storage and other aspects of the content. Consider the feasibility of the application of the traditional enterprise information system.

First of all, for the NoSQL database, in the database modeling needs to focus on, completely abandon the traditional relational database modeling method, if the traditional relational database tables intact mapping to the NoSQL database, many NoSQL database itself is not useful characteristics of the advantages. One of the most important is to transform into the face of the object of the thinking mode, more attention to domain objects and entity information. The collection of MongoDB databases itself is a hierarchical document object that can be all-encompassing, and the collection itself can contain subcollections to form an object of complete meaning.

If you take one of the simplest enterprise customer information management functions, you can see the first to maintain the enterprise customers, business customers commonly used contacts, each person's contact information, enterprise-related information documents, business addresses, business account information, to fight for corporate visits records, etc. This is about one of the simplest Enterprise Client domain object information.

According to the truth, the enterprise information is a complete object, the enterprise subordinate objects are subordinate to the enterprise this object, the enterprise this information without the rest of the information of the subject of the life cycle will also end. If you only need a resume in this sense, you can manage everything with a collection collection. But I see enterprise customers include two aspects of information, one is static information, such as enterprise basic information, contacts, contact address information, one is the dynamic information, that is, the company's visit records. Considering the change of the enterprise visit record itself is the dynamic information, the enterprise visiting record can be separated as a document object to manage. If so, to improve the above features only need to build two document objects, one is the basic information of enterprise customers, one is to visit the record information. In addition, there is a file storage function, directly using MongoDB Gridfs to complete.

In enterprise customer information, the Enterprise customer is a collection, in which the contact information is a sub-collection, contact contact information (multiple contacts) can be two points of consideration, one is double collection, you can directly merge a variety of contacts into the contact object layer, Because MongoDB's attribute fields can be easily extended by themselves, this design can reduce the level of the entire collection. (My consideration here is that for a 1-to-many relationship, only one field for the child table itself can be considered for merging into the parent object to reduce the hierarchy). This information is often in the customer basic information input when the need for full input, a complete JSON object format can be easily as a whole to be deposited into the MongoDB database.

For customer visit records because of the constant increase in dynamic, you can set up an object, in which the customer ID, customer name information redundancy, reduce the subsequent query function unnecessary Object Association. For this object we can see that the data is often increased, but the actual increase in the data itself is very small. In the visit record, if there are pictures or document storage related to this visit, it can also solve the problem.

For the customer document data storage, the above has been said directly using Gridfs to complete. Gridfs is a built-in feature of MongoDB that provides a set of file-manipulation APIs to leverage MongoDB to store files. As you can see from the previous scenario, the store that adds a customer profile calls the File Store API to complete the storage of the unstructured file, which can be returned with the file handle ID, which can be stored directly on the client's main collection object as a sub-collection. You can also create a separate association table for the ID of the customer ID and file handle, but the individual thinks it seems better to build directly on the Customer Master collection object.

Based on the above basic ideas to analyze the actual customer information management needs of the specific function points.

Customer information new features, in the new interface need to maintain basic customer information, customer contact, address information, customer documentation information, if not consider the non-structural document attachments, the entire page itself is a complete JSON object, can only be called once to complete the entire hierarchical collection object storage, and quite simple. Considering the attachment information, the operation is divided into two steps, first uploading the storage attachment to get the attachment handle ID, and then storing the structured customer base object information. For the customer visit record information, input customer visit record must first be to select to specific customer, select to specific customer, customer ID information, customer's name information is already can get to. Adding a new call record is also a fairly simple operation that can be done.

Look at the query function, first of all, the customer information query may be a fuzzy query function, and MongoDB for fuzzy query performance is relatively weak, so as far as possible to reduce unnecessary fuzzy query fields, for the necessary query fields can be added to the MongoDB object index information. The most important thing is that the support for join operation is weak based on MongoDB database, so we should reduce unnecessary object association operation in data Model design and query design as much as possible. When a specific customer information is queried, it is fairly straightforward to look at the customer's specific visit record, which is simply a class where operation based on the customer ID that is easiest to visit the record table. For the customer specific attachment list information can do similar design, that is, click on the link and then go to the specific customer attachment document viewing interface.

For the update function, the basic object update is quite simple, the rest is for the contact information updates, the contact information is a sub-collection object, where it is not yet seen whether it is necessary to update the sub-collection object, or you can only update the operation sub-collection object in a record. For the update operation, you still need to navigate to the specific ID value before updating. For bulk updates Now MongoDB itself also provides the appropriate operation, similar to the batch update customer state operation is very easy to implement.

The above is only one of the simplest analysis, based on this analysis, in the future for similar master data management system applications can be migrated to the MongoDB database to support. In addition, for records to be updated infrequently, it is also appropriate to migrate to a MongoDB database if the objects are directly interrelated and have little impact. In the process of using NoSQL database, we should avoid such scenarios as strong consistency requirement, complicated relationship between tables and long-period transaction.

"Reprint" on MongoDB's application scenario