MongoDB Core Concepts Part 2

Ok, so now that we’ve covered the fact that relational technologies were (in large part) created with a primary goal of maximizing efficiency of disk space by leveraging a system of references – multiple tables to store data only once and refer to it multiple times, let’s take a look at another system of storage that provides a different set of efficiencies.

JSON Document Structure

MongoDB is NOT a JSON database… I like to say that right out of the gate.  Sometimes people will inaccurately report that MongoDB is a JSON database or that it stores data in JSON.  It does not.  It does, however, support JSON fully.

MongoDB stores data in BSON.  There’s a full specification over at BSONspec.org if you’re interested in the gory details.  What’s the difference, you might be asking?  Hang on… we’ll get there.

Let’s start with a view of the difference between how we store data in the relational world, vs. how we store data in JSON/BSON.

First, a bit of terminology to make sure we’re all on the same verbal page.

RDBMSMongoDB
TableCollection
RowDocument
ColumnField
Secondary IndexSecondary Index
JoinsEmbedded documents, linking, $lookup & $graphLookup
GROUP_BYAggregation Pipeline

Now, if you’re like me and have developed applications designed to run with a relational database backend, you’ll naturally begin to think about the data elements you’ll manage in your applications and break them into distinct types… maybe even calling them tables… defining the columns for each different piece of data you’ll store and manage.  Further, you’re likely to start thinking about multiple tables for very different pieces of information or data.  For example, People and Cars.  If we’re developing an application that will manage people and the cars they own, you’ll likely end up with something that looks like the following:

Now this is quite logical, especially in light of the fact that you’ve likely been devising these relational schemas for quite some time.

Now to create this structure, we need to develop some DDL, or Data Definition Language.  This, in relational parlance is how we create a schema.  In a RDBMS, the schema lives separately from the data.

View SQL Schema

This is part of the problem associated with relational technologies.  All of that definition language above is not needed if we don’t have a schema… if we don’t care about establishing constraints and column definitions ahead of time.

Instead, we can immediately concentrate on creating documents right in our code.  Let’s look at a simple example using NodeJS.

This simple example will insert one document into a collection called peoplecars in a database also called peoplecars.

The document looks like this:

This simple example was written in NodeJS, but know that there are drivers for literally every modern language.  Here are links to just a few:

I hope you found this introduction useful.  If you have questions or want to learn more, reach out!  Use the comment box or contact me on Twitter.

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *