Getting Started with MongoDB

MongoDB possesses significant capabilities. A document in MongoDB serves as the fundamental data unit, which can be likened to a row in a relational database management system, but with significantly greater expressive capabilities.

• Likewise, a collection can be considered as the table's schema-free counterpart. 
• MongoDB can support several autonomous databases inside a single instance, with each database having its own collections and permissions.
• MongoDB includes a straightforward yet robust JavaScript shell that is valuable for managing MongoDB instances and manipulating data.

Each document in a collection is assigned a unique key called "_id".

---

Documents

---

The core of MongoDB revolves around the notion of a document, which is a structured collection of keys and their corresponding values. The way a document is represented varies depending on the computer language used. However, most languages offer a data structure that is well-suited for this purpose, such as a map, hash, or dictionary. In JavaScript, documents are represented as objects, such as:

{"greeting" : "Hello, world!"}

This simple document contains a single key, "greeting", with a value of "Hello, world!". Most documents will be more complex than this simple one and often will contain multiple key/value pairs:

{"greeting" : "Hello, world!", "foo" : 3}

The keys within a document are represented as strings. Any character encoded in the UTF-8 character set is permissible as a key, where a few specific exclusions are as follows:

• Keys must not include the null character (\0). This character is employed to denote the conclusion of a key.
• The characters "." and "$" possess unique qualities and should be employed exclusively in specific situations, as elucidated in subsequent chapters. Typically, they should be regarded as off-limits, and drivers will express dissatisfaction if they are utilized improperly. 
• Keys that begin with an underscore (_) should be regarded as reserved, however, this rule is not strictly followed.

---

Collections

---

A collection is a group of documents. If a document is the MongoDB analog of a row in a relational database, then a collection can be thought of as the analog to a table.

 

Collections are schema-free. This means that the documents within a single collection can have any number of different “shapes.” For example, both of the following documents could be stored in a single collection:

  {"greeting" : "Hello, world!"}
  {"foo" : 5}
  

It is important to observe that the previous documents not only had distinct data types for their values (such as string and integer) but also have completely dissimilar keys. The question of the necessity of different collections sometimes arises due to the fact that any document can be included in any collection. It is a valid inquiry. If there is no requirement for distinct schemas for various types of documents, what is the rationale for utilizing more than one collection? There are multiple compelling justifications:

• Storing many types of documents in a single collection can be extremely challenging for developers and administrators. Developers must ensure that each query exclusively retrieves documents of a specific type or that the application code executing the query can handle documents with varying structures. When searching for blog entries, it is difficult to filter away documents that include information about the author. 
• Obtaining a list of collections is far quicker than extracting a list of the types within a collection. For instance, if we had a categorical attribute in the collection indicating whether each document is classified as "skim," "whole," or "chunky monkey," it would be more time-consuming to retrieve these three values from a single collection compared to having three separate collections and querying for their respective names. 
• Organizing documents of similar nature in a single collection enables data localization. Retrieving multiple blog posts from a collection that simply contains posts will generally need fewer disk operations compared to retrieving the same posts from a collection that includes both posts and author data.
• Indexes are created to introduce organization and structure to our texts. These indices are specifically defined for each collection. By consolidating documents of the same type into a single collection, we may optimize the indexing process for our collections.

Naming

A collection is uniquely identified by its name. Collection names can consist of any UTF-8 string, although there are a few limitations: 

• The empty string ("") is an invalid collection name. 
• Collection names cannot include the null character (\0) as it signifies the end of a collection name.
• It is advised not to build collections that begin with the prefix "system.", as this prefix is specifically designated for system collections. As an illustration, the system.users collection holds the users of the database, whereas the system.namespaces collection stores information on all the collections in the database. 
• User-generated collections must not include the reserved letter $ in their name. The database drivers offer support for utilizing the $ symbol in collection names due to the presence of system-generated collections that include it. Avoid using the symbol $ in a name, unless you are specifically accessing one of these collections.

Subcollections

One convention for organizing collections is to use namespaced subcollections separated by the . character. For example, an application containing a blog might have a collection named blog.posts and a separate collection named blog.authors. This is for organizational purposes only—there is no relationship between the blog collection (it doesn’t even have to exist) and its “children.”

---

Happy Exploring!