Module
Module 2 of 6Lesson 3 of 3~12 min

Relational or document database, and what it changes for you

Relational or document: this storage choice shapes which questions your product will be able to ask of its data. The lesson gives you a framework for comparing the two approaches against a specific need and discussing it as a peer with the engineering team. You also know where your analyses will happen, whichever option wins.

Lesson objective

By the end of this lesson, you will be able to compare a relational database and a document (NoSQL) database on four criteria (shape of the data, expected queries, consistency, schema change), justify a choice for a product need and say where analysis will happen in each case.

Topics covered

  • SQL vs NoSQL
  • relational database
  • document database
  • data schema
  • data warehouse

Where it fits

Read and model data

How do my product's screens translate into tables, and how do I design the tables for my next feature?

Lessons in this module

  1. Read a data model, from screens to tables
  2. Model the data of a feature
  3. Relational or document database, and what it changes for you (this lesson)

What you will learn in the course

This lesson is part of the course Model your product’s data and query it with SQL

  • Read a data model (tables, primary and foreign keys, cardinalities, entity-relationship diagram) and connect it to the product's screens and rules.
  • Model the data of a feature (entities, attributes, relationships, keys, cardinalities) and get the model validated by the engineering team.
  • Compare a relational database and a document (NoSQL) database for a product need and justify the choice based on expected queries, consistency and change.
  • Write queries that filter, sort and aggregate (SELECT, WHERE, ORDER BY, GROUP BY, HAVING) while handling NULL values and dates correctly.
  • Combine several tables with INNER and LEFT joins, and check that the result neither loses nor duplicates any row.
  • Turn a product question into a verifiable query, using CTEs and simple window functions (ROW_NUMBER, LAG, SUM OVER).
  • Query data read-only while protecting personal data, and have an AI draft SQL while checking every query before using its result.