Why Mongo?

- [Instructor] I'm going to talk now about how MongoDB is different from other types of databases. For decades, relational databases were the gold standard for data management and processing. Enterprises and smaller companies work with SQL-enabled relational databases. These databases are organized by table with each discrete type of data contained within specific tables for that data type, like an address or a phone number, or even invoice numbers. Keys are used to type data between the different tables in order to construct complete data models.

Relational databases can be very complex for relatively simple schemas. For instance, a user in the system might have one or more addresses, phone numbers, or job titles. In order to retrieve information about one single entity, multiple tables need to be queried and the data tied together. This image shows the pieces necessary to show the data for just one user. Creating relational database schemas can have several disadvantages. The development and design can be complex and require the work of knowledgeable database administrators.

Changes to the schema require a change to the entire database system, and a potentially expensive update operation, and getting a fairly simple representation of an object in the database, such as the user above, requires a relatively complex database operation. Imagine how much more complicated it would be to retrieve a more detailed object. Relational databases were created with the idea of having dedicated database administrators, where Mongo and other NoSql systems were designed to be accessible to programmers.

The object oriented nature of the documents better matches the way that many software engineers work with data. Gathering appropriate information can be expensive in terms of time and resources when multiple intersecting joins are needed to aggregate information. Here's an example of the call needed to find all the users named John in the system along with their related contact information. When the data is returned, it is combined into a single table with the requested information. A document database, on the other hand, keeps all of the related information contained in the same object, so it's easier to access the information.

On this screen, the Mongo shell is started. The first item is inserted into the users collection. Note that this collection is created dynamically when the item is inserted. After the second item is input, it's a simple request to get a list of all items in the database. Here's a request for all the documents in the system containing John as the first name. When making your requests for documents in Mongo, you include a document in the request describing the characteristics of the objects you want to get back. The documents themselves already contain all of the appropriate fields, so no specific join operation needs to happen.

The second example here shows one of the great features of Mongo. When a document doesn't match the exact query, it simply isn't returned. No error is returned for the missing field. Different types of similar data can be contained within the same collection, and we'll see more about that in the following sections. Finally, Mongo is simply designed to be extremely friendly to developers. The JSON representation makes it easy to parse through and understand the database contents. JavaScript shell axis is a natural interface for programmers.

Excellent open source drivers are available for most major languages created, maintained, and supported by MongoDB Incorporated, formerly TenGen, and Mongo is used by companies to handle extensive data storage challenges.