Many of the components that go into the MongoDB data structure have their counterparts in relational database management systems based on the Structured Query Language (SQL).
The following table describes the MongoDB data objects and shows how they map to SQL data objects.
If you have a background in relational databases, you can use this MongoDB vs SQL data object comparison as a quick reference to better understand the MongoDB data structure as you work through the lesson.
|MongoDB object||Description||SQL object|
|database||A container for holding document collections. A MongoDB instance can support multiple databases. Each database is associated with its own set of files. MongoDB creates these files when you add the first collection. The database does not physically exist until you add that collection.||database|
|collection||A grouping of documents in a common namespace. Unlike an SQL table, documents within the same collection can have different structures, resulting in more flexibility than you get with an SQL database.||table|
|document||Basic unit of data in a MongoDB database. MongoDB leverages the Extended JSON format to store and work with documents. In the background, MongoDB uses BSON (binary plus JSON) to represent the documents. BSON is a binary-encoded format that extends the JSON model to provide additional data types and other capabilities.||row (or record)|
|field||A name-value pair in which the value conforms to a BSON data type. MongoDB automatically assigns data types to the field values when you add a document to a collection. You can override this behavior by using a constructor in the document definition to specify a data type.||column|
|data type||A data attribute that enforces the type of data that can be used in a field. Each field is assigned a data type.||data type|
|primary key||A required value that uniquely identifies a document within a collection. The primary key is always implemented as the _id field.|
Terms you might not know:
name-value pair: a common way of giving data meaning, whereby one half of the pair holds the data and the other half of the pair holds an attribute that describes the data. One common example might be an attribute, or name of “First Name” and the data, or value of “Thomas” (source)