上QQ阅读APP看书，第一时间看更新

Document design

When designing documents, which will ultimately end up in collections, one way to start off the design process would be to gain an understanding of what outputs (such as printed reports, or data that will be pulled up on a screen at some point). You can then work your way backwards to decide which documents need to be created. As an example, let's take the one shown just now: customers, products, and purchases.

If at some point you need to print a customer report, it might be appropriate to design a customer collection. You should only include information that needs to go into the report. In a like manner, you might have an inventory of products that need to be tracked. You would then design a product collection, including only the information which needs to appear in the report or on a screen display:

When we get to purchases, it gets a little tricky. Probably the most difficult aspect of document design is to shake off your SQL viewpoint, if that is your background. The SQL way of doing things would be to design a minimal purchase document, and have a reference to the associated customer and product documents. As mentioned previously, this would introduce tremendous difficulties when it comes time to querying and producing any output. A more expedient design would be simply to embed the associated documents inside the purchase document:

Another situation where SQL-based thinking will not serve you well is when you want to implement a series of lookup tables. For example, let's say you want to populate an HTML SELECT form element from a database. As an example, let's assume the first select element gives users a choice of social media; Facebook, Twitter, Instagram, and so on. The other select element consists of a list of categories; Shirts, Blouses, Jeans, Jackets, Footwear, and so on.

If you are thinking in SQL terms, you would probably create a table for each type, and then have a single row for each item. As an example, you might have a table called social_media with the two columns id and type, where type would be Facebook, Twitter, and so on:

You would then create a table categories, again with the two columns id and category, where category would be Shirts, Blouses, and so on:

To do the same thing in MongoDB, you might create a collection called select_options, with two documents. The first document would have a field type, with a value Social Media. A second field would be an array that includes Facebook, Twitter, and so on. The second document would also have a field type with a value Categories.

The second field would be an array with Shirts, Blouses, and so on:

Any time you find yourself creating a large set of small documents, consider collapsing the collection into a single document with an embedded array. A good overview of data design is found here: https://docs.mongodb.com/manual/core/data-model-design/.