Understanding Document Databases

Document databases have become a popular choice among developers due to their flexibility and scalability. In our introduction, we will present an alternative to relational databases and explore the diverse range of applications they offer.

Transition from Relational to NoSQL Databases

For a long time, relational databases dominated the database landscape, organizing data into tables with rows. However, in recent years, various database types have emerged that break away from the rigid structure of the relational model. These new database models are collectively referred to as NoSQL databases because they typically do not use a structured query language, as is typical in relational databases, for data management and querying.

NoSQL databases offer a high degree of scalability and flexibility regarding data structure. These features make NoSQL databases useful for handling large volumes of data and for rapid, agile development.

Key Concepts and Benefits of Document Databases

In the following sections, we will explain the key concepts related to document databases and the benefits of their use. While our examples will reference MongoDB, a widely used document-specific database, the highlighted concepts are applicable to most other document databases as well.

What Is a Document Database?

Document-oriented databases store data as documents. You can think of such a document as a self-contained record that contains everything needed to understand its meaning, similar to documents used in the real world.

Here is an example document that could appear in a document database like MongoDB. It represents a company contact card and describes a centron employee named Anna:

{
    "_id": "annameier",
    "firstName": "anna",
    "lastName": "meier",
    "email": "anna.meier@centron.de",
    "department": "Development"
}

All data in JSON documents is represented as field-value pairs in the form of Field: Value. In the previous example, the first line shows a field named “_id” with the value “annameier.” The example also includes fields for the employee’s first name, last name, email address, and department.

Field names allow you to understand at a glance what type of data is contained in a document. Documents in document databases are self-descriptive, meaning they include both the data values and information about the type of data being stored. When retrieving a document from the database, you always get the complete picture.

Here is another example document representing a colleague of Anna named Tobias. He works in multiple departments and also has a middle name:

{
    "_id": "tobiasweber",
    "firstName": "Tobias",
    "middleName": "Andreas",
    "lastName": "Weber",
    "email": "tobias.weber@centron.de",
    "department": ["Development", "Sales"]
}

Since these documents contain different data fields, you can say that they have different schemas. A database’s schema is its formal structure that describes what type of data it can store. In the case of documents, their schemas are reflected in their field names and the types of values these fields represent.

In a relational database, you couldn’t store these two sample contact cards in the same table because they differ in structure. You would need to adjust the database schema to allow for storing multiple departments or middle names and either add a middle name for Anna or fill the column for that row with a NULL value. This is not the case with document databases, which give you the freedom to store different documents with different schemas without altering the database itself.

In document databases, documents are not only self-descriptive but their schema is also dynamic. This means you don’t have to predefine it before storing data. Fields can vary between different documents in the same database, and you can change the document’s structure as desired by adding or removing fields. Documents can also be nested, meaning a field in one document can have a value in the form of another document, allowing you to store complex data within a single document.

For instance, suppose the contact card needs to store information about the employee’s social media accounts and include them as nested objects in the document:

{
    "_id": "tobiasweber",
    "firstName": "Tobias",
    "middleName": "Andreas",
    "lastName": "Weber",
    "email": "tobias.weber@centron.de",
    "department": ["Development", "Sales"],
    "socialMediaAccounts": [
        {