MongoDB to Couchbase, Part 4: Data Modeling

To Embed or Not to Embed. That is the Question.  - Hamlet

Data modeling is a well-defined and mature field in relational database systems. The model provides a consistent framework for application developers to add and manipulate the data. Everything is great until you need to change. This lack of schema flexibility was a key trigger for NoSQL database systems.  As we've learned before, both MongoDB and Couchbase are JSON-based document databases. JSON gives the developers schema flexibility: the indexes, collections, query engine provide access paths to this data. The developer uses MQL in MongoDB and N1QL in Couchbase to query this data.  Let's compare the modeling methods in Couchbase. Note: This article is short because the modeling options are similar. That's a good thing. Some differences in modeling options, access methods, and optimizations are highlighted below.

MongoDB to Couchbase (Part 3): Data Types

 In the article on MongoDB and Couchbase database objects, we saw the mapping from databases to buckets, collections to collections, documents to documents, and field to fields. The data itself is stored within these fields. The {"field": "value"} is commonly called key-value pairs. Every key has a value and the value is the data. This value self describes the data under  BSON or JSON definition in MongoDB and Couchbase.

MongoDB uses BSON, Couchbase uses JSON -- both are document-oriented and JSON-based. Couchbase uses JSON exactly, MongoDB uses extended JSON called BSON, binary JSON.

MongoDB to Couchbase for Developers, Part 1: Architecture

Introduction

With this article on MongoDB to Couchbase comparison, I'm starting a new, detailed series for MongoDB developers to learn Couchbase by comparison. Two years ago, I wrote a single high-level comparative article on MongoDB and Couchbase.  I recommend you read that for a bird's view comparison. Both MongoDB and Couchbase have done multiple major releases since then, and developers need a deeper treatment of topics. As developers know, the devil is in the details :-) 

This series will be similar to the series for Oracle developers to learn Couchbase by comparison, but for MongoDB developers.  

BSON Data Types — ObjectId

BSON Data Types — ObjectId

In the database world, it is frequently important to have unique identifiers associated with a record. In a legacy, tabular database, these unique identifiers are often used as primary keys. In a modern database, such as MongoDB, we need a unique identifier in an `_id` field as a primary key as well. MongoDB provides an automatic unique identifier for the `_id` field in the form of an `ObjectId` data type.

For those that are familiar with MongoDB Documents, you've likely come across the `ObjectId` data type in the `_id` field. For those unfamiliar with MongoDB Documents, the [ObjectId](https://alger.me/mongodb-objectid) datatype is automatically generated as a unique document identifier if no other identifier is provided. But what is an `ObjectId` field? What makes them unique? This post will unveil some of the magic behind the BSON ObjectId data type. First, though, what is BSON?