MongoDB Terminology in Relational Database Terms 316

Introduction

A lot companies are making the shift from traditional relational database SQL technologies like Postgres and MySQL to NoSQL technologies like MongoDB. For developers making the shift a hurdle in the learning curve is understanding the new terminology. What is a “Collection”? What is a “Document”? It helps to begin explaining these terms in the terms of relational databases so that developers can jump over those initial hurdles. In this article we’ll do just that. We’ll explain the terminology in MongoDB in terms of relational database terms so you can speak the language. If you don’t have any experience with MongoDB or NoSQL you might think that the technologies are so different that they can’t be explained using the same terms, but for the most part, the terms in MongoDB easily translate to relational database terms. Now let’s get started!

Database

Luckily, a database is still a database. These term doesn’t change and they are both the same conceptually. There should be no confusion here because this term translates exactly.

Collection are Tables

A Collection in MongoDB is what relational databases would refer to as a Table. Like Tables, these Collections contain entries of data and a new Collection (Table) is typically made for every different type of entity (User, Account, Product etc). Like in relational database technologies, a Database is typically composed of many tables, and in MongoDB a Database is typically composed of many Collections. So when someone talking about MongoDB mentions “Collection”, think “Table”.

In SQL Tables typically have many columns with varying data types but this is where the departure starts for NoSQL systems like MongoDB. We’ll jump into this more when we jump into the next section about Records.

Documents are Records

A Document in MongoDB is what relational databases would refer to as a Record. Like in SQL, you typically have many Records in a Table, and in MongoDB you’ll typically have many Documents in a Collection.

Visualize the Difference

Now that we have related the basic terminology to relational databases, we think it helps to show the difference visually.

Let’s first take a look at what a Table would look like in a SQL database. We’ll be using the example of a database for a small-town grocery store. This Database is called groceryDB and this Table is called products which contains 6 Records:

Now let’s recreate this in MongoDB. The Database directly translates to a Database in MongoDB so we can still have a Database named groceryDB. Now instead of a Table named products we will have a Collection named products. Now the main difference comes in when we try and replicate the Records into Documents. Let’s see how the Documents would look and then we’ll dissect why they are so different.

The first thing you’ll notice is that the JSON structure of these Documents that MongoDB uses. And for now the Document maps pretty directly to a Record, but the key thing about MongoDB and NoSQL Databases is that the Collections DON’T define what data fields need to be in the Documents. For example, you could add this Document to our products Collection with zero problems:

Notice that we still have the name field but we don’t have any of the other fields and we have added a new field numSold. This is a the big departure for NoSQL databases like MongoDB. You don’t have to define any schema, your Documents can have whatever data you’d like.

The Confusion on Joins

Now joins are often a point of confusion when going from relational database systems to MongoDB. While you can do joins in MongoDB, there is an Embedded Document structure which would be the recommended way to do that. So in our example, you could join a product to another Document with information about it’s vendor, but you could also embed it within the document like so:

In this format whenever you query the product Document you would get all the information about the vendor without doing a join.

Conclusion

We have gone over what we think are the primary terminology hurdles when moving from relational databases to NoSQL technologies like MongoDB. We encourage you to explore MongoDB more and see if it’s a technology that would work well for your application. If you need any assistance setting a MongoDB database please don’t hesitate to reach out to us at Object Rocket.