What is a Document Database?

– MongoDB
A document database (also known as a document-oriented database or a document store)
is a database that stores information in documents.

A document is a record in a document database. A document typically stores information

about one object and any of its related metadata.

Documents store data in field-value pairs. The values can be a variety of types and
structures, including strings, numbers, dates, arrays, or objects. Documents can be stored
in formats like JSON and XML.

Below is a JSON document that stores information about a user named Tom.
{

"_id": 1,

"first_name": "Tom",

"email": "[email protected]",

"cell": "765-555-5555",

"likes": [

"fashion",

"spas",

"shopping"

],

"businesses": [

"name": "Entertainment 1080",

"partner": "Jean",

"status": "Bankrupt",

"date_founded": {

"$date": "2012-05-19T04:00:00Z"

},

"name": "Swag for Tweens",

"date_founded": {

"$date": "2012-11-01T04:00:00Z"

}
Collections
A collection is a group of documents. Collections typically store documents that have
similar contents.

Not all documents in a collection are required to have the same fields, because document
databases have flexible schemas.

Continuing with the example above, the document with information about Tom could be
stored in a collection named users. More documents could be added to
the users collection in order to store information about other users. For example, the
document below that stores information about Donna could be added to
the users collection.

"_id": 2,

"first_name": "Donna",

"email": "[email protected]",

"spouse": "Joe",

"likes": [

"spas",

"shopping",

"live tweeting"

],

"businesses": [

"name": "Castle Realty",

"status": "Thriving",

"date_founded": {

"$date": "2013-11-21T04:00:00Z"

}
 }

Note that the document for Donna does not contain the same fields as the document for
Tom. The users collection is leveraging a flexible schema to store the information that
exists for each user.

CRUD operations
Document databases typically have an API or query language that allows developers to
execute the CRUD (create, read, update, and delete) operations.

• Create: Documents can be created in the database. Each document has a unique
identifier.

• Read: Documents can be read from the database. The API or query language allows
developers to query for documents using their unique identifiers or field values.
Indexes can be added to the database in order to increase read performance.

• Update: Existing documents can be updated — either in whole or in part.

• Delete: Documents can be deleted from the database.

What are the key features of document databases?

Document databases have the following key features:

• Document model: Data is stored in documents (unlike other databases that store
data in structures like tables or graphs). Documents map to objects in most popular
programming languages, which allows developers to rapidly develop their
applications.

• Flexible schema: Document databases have flexible schemas, meaning that not all
documents in a collection need to have the same fields.

• Distributed and resilient: Document databases are distributed, which allows for
horizontal scaling (typically cheaper than vertical scaling) and data distribution.
Document databases provide resiliency through replication.

• Querying through an API or query language: Document databases have an API or

query language that allows developers to execute the CRUD operations on the
 database. Developers have the ability to query for documents based on unique
identifiers or field values.

How much easier are documents to work with than tables?

Developers commonly find working with data in documents to be easier and more intuitive
than working with data in tables. Documents map to data structures in most popular
programming languages. Developers don't have to worry about manually splitting related
data across multiple tables when storing it or joining it back together when retrieving it.
They also don't need to use an ORM to handle manipulating the data for them. Instead,
they can easily work with the data directly in their applications.

Let's take another look at a document for a user named Tom.

Users

{
"_id": 1,
"first_name": "Tom",
"email": "[email protected]",
"cell": "765-555-5555",
"likes": [
"fashion",
"spas",
"shopping"
],
"businesses": [
{
"name": "Entertainment 1080",
"partner": "Jean",
"status": "Bankrupt",
"date_founded": {
"$date": "2012-05-19T04:00:00Z"
}
},
{
"name": "Swag for Tweens",
"date_founded": {
"$date": "2012-11-01T04:00:00Z"
}
}
]
}
All of the information about Tom is stored in a single document.
Now let's consider how we can store that same information in a relational database. We'll
begin by creating a table that stores the basic information about the user.

Users

ID first_name email cell

1 Tom [email protected] 765-555-5555

A user can like many things (meaning there is a one-to-many relationship between a user
and likes), so we will create a new table named "Likes" to store a user’s likes. The Likes
table will have a foreign key that references the ID column in the Users table.

Likes

ID user_id like

10 1 fashion

11 1 spas

12 1 shopping

Similarly, a user can run many businesses, so we will create a new table named
"Businesses" to store business information. The Businesses table will have a foreign key
that references the ID column in the Users table.

Businesses
 ID user_id name partner status date_founded

20 1 Entertainment 1080 Jean Bankrupt 2011-05-19

21 1 Swag for Tweens NULL NULL 2012-11-01

In this simple example,

we see that data about a user could be stored in a single document in a document
database or three tables in a relational database.

When a developer wants to retrieve or update information about a user in the document
database, they can write one query with zero joins. Interacting with the database is
straightforward, and modeling the data in the database is intuitive.