NoSQL, MongoDB & Spring Data

Notebook Summary

Hand-copy this. Terse rules and the boxed markers; the full reasoning is in Section 2.

Detailed Study Notes

You are building the product catalog for QEats — an app that lists restaurants and dishes. You start where every backend course starts: a relational database. A restaurants table, a menu_items table, an attributes table, a reviews table, all wired together with foreign keys. Rendering one restaurant page means joining five tables. Then the product team says: "some restaurants have opening hours per weekday, some have a single flat time, and a few now have delivery zones." Your neat schema does not have a column for that, and adding one means an ALTER TABLE on a table with millions of rows. This is the moment the relational model starts fighting you — and the reason document databases exist.

2.1 Where relational databases start to hurt

A relational database (SQL) stores data as rows in fixed-column tables and rebuilds related data on demand by joining tables together. That model is excellent for well-understood, highly structured data with strong consistency needs — banking, inventory, anything where a row must never be half-written. It stops being comfortable in three specific ways, and the lesson named all three.

The Amazon-products test [+]

The session ran a thought experiment: look at two very different Amazon listings — a running shoe and a smartphone. The shoe has size, color, material. The phone has RAM, storage, screen size, battery. Will one fixed RDBMS schema hold both? Either you create a wide table full of columns that are NULL for most products, or you build an "attributes" side-table and JOIN it back for every read. Both are awkward. This is the classic case where each product is naturally one flexible document with whatever fields it needs — and nothing more.

2.2 What NoSQL actually means

NoSQL is a family of non-relational databases that drop the fixed-table, JOIN-based model in favor of flexible, self-contained records that are easy to distribute across many machines. "NoSQL" is best read as "not only SQL" — not "SQL is forbidden," but "the relational model is no longer the only option." The shared traits the lesson emphasized:

• Non-relational — data is not forced into rows-and-columns with foreign keys.
• Schema-less — records in the same collection can have different fields; you are not locked to one shape.
• Basically a large serialized-object store — you save an object roughly as-is, instead of shredding it across tables.
• No JOINs, so no complicated multi-table queries — you fetch a record whole.
• Distributed out of the box — scaling across machines is the default assumption, not an afterthought.

The four families

NoSQL is an umbrella. The lesson grouped it into four types by how a record is shaped. MongoDB lives in the document family.

2.3 The mental model shift: tables → documents

MongoDB stores data as documents — JSON-shaped bundles of key–value pairs — grouped into collections, where a collection plays the role a table played in SQL. The single most useful thing you can carry out of this lesson is the vocabulary map between the two worlds, because every Mongo concept has a relational cousin.

Two ideas deserve their own paragraph. First, a document is just key–value pairs — the same JSON you already send over HTTP. Mongo actually stores it as BSON (Binary JSON), a compact binary form that adds types like dates and 64-bit ints, but you read and write it as JSON. Second, a collection holds a set of documents and behaves like a table — except it does not impose fixed columns, so two documents in the same collection can legitimately have different fields.

2.4 Why MongoDB specifically

MongoDB is the leading document database: it stores each entity as one JSON-shaped document, lets related data live nested inside that document, and distributes collections across machines by default. Restating the two building blocks the session drilled:

• Documents consist of key–value pairs. The unit of storage is one JSON object.
• Collections contain sets of documents and are almost equivalent to relational tables — but without a fixed column list forced on every row.

The practical payoff: for a read-heavy catalog, you fetch a whole product — attributes, reviews, images — in a single query against a single collection. No join planner, no five-table read path, and when the shoe needs a material field the phone will never have, you simply add it to the shoe documents.

2.5 CRUD — talking to Mongo directly

CRUD is the four things you ever do to stored data — Create, Read, Update, Delete — and Mongo gives each a method you call on a collection. Before any framework hides it, it is worth seeing the raw shell commands, because Spring Data is only a thin wrapper over exactly these.

// CREATE — insert one document (Mongo adds _id automatically)
db.products.insertOne({ name: "Shoe", price: 2499, color: "red" })

// CREATE many at once
db.products.insertMany([
  { name: "Phone", price: 10999, ram: 6 },
  { name: "Cap",   price: 399 }
])

// READ — filter is itself a document; {} matches everything
db.products.find({ color: "red" })
db.products.findOne({ name: "Phone" })

// READ with an operator — price greater than 500
db.products.find({ price: { $gt: 500 } })

// UPDATE — $set changes only the named fields
db.products.updateOne(
  { name: "Shoe" },
  { $set: { price: 1999 } }
)

// DELETE
db.products.deleteOne({ name: "Cap" })

Two patterns run through all of it. A query is just a document describing what to match — { color: "red" } means "field color equals red." And query operators start with $: $gt greater-than, $lt less-than, $in in-a-list, $set set-fields. Once you see that filters and updates are themselves documents, the whole query language stops feeling like new syntax.

2.6 Spring Data MongoDB — the Java layer

Spring Data MongoDB lets you work with documents as plain Java objects: you annotate a class, extend a repository interface, and Spring generates the CRUD and query code for you. This is how QEats actually talks to Mongo — you almost never write shell commands in the app. Three pieces do all the work.

@Document(collection = "products")
public class Product {

    @Id
    private String id;          // maps to Mongo's _id

    private String name;
    private int price;
    private String color;

    // constructors, getters, setters …
}

public interface ProductRepository extends MongoRepository<Product, String> {

    // Derived query — Spring parses the METHOD NAME into a query.
    // This becomes: find({ color: ? })
    List<Product> findByColor(String color);

    // Becomes: find({ price: { $gt: ? } })
    List<Product> findByPriceGreaterThan(int price);
}

@Service
public class ProductService {

    private final ProductRepository repo;

    public ProductService(ProductRepository repo) {
        this.repo = repo;             // constructor injection
    }

    public Product add(Product p) {
        return repo.save(p);          // CREATE (and UPDATE if id exists)
    }

    public List<Product> redProducts() {
        return repo.findByColor("red");   // derived query
    }
}

The layered path a QEats request takes down to the document store.

Interview & Practice Q&A

The follow-ups this material invites. Try to answer aloud before expanding.

Key Takeaways

• SQL hurts at scale on three axes: hard horizontal scaling, rigid schema, costly JOINs.
• NoSQL = non-relational, schema-less, no JOINs, distributed by default; four families, Mongo is document.
• Term map: table→collection, row→document, column→field, PK→_id, JOIN→embed.
• Model by access pattern — store together what you read together.
• A query is a document; operators start with $; $set updates only named fields.
• Spring Data: @Document + @Id + MongoRepository = CRUD and derived queries for free.

Microexercises

Reading proves you recognize it; these prove you can use it. Attempt each before opening the walkthrough.

3.1 Build-it — a Spring Data repository query

@Document(collection = "products")
public class Product {
    @Id private String id;
    private String name;
    private int price;
    private String color;
    // getters / setters …
}

public interface ProductRepository extends MongoRepository<Product, String> {
    // TODO: add the three derived queries
}

public interface ProductRepository extends MongoRepository<Product, String> {

    List<Product> findByColor(String color);

    List<Product> findByPriceLessThan(int price);

    List<Product> findByColorAndPriceLessThan(String color, int price);
}

3.2 Diagnose-it — the vanishing fields

db.products.insertOne({ name: "Shoe", price: 2499, color: "red" })

db.products.updateOne(
  { name: "Shoe" },
  { price: 1999 }        // meant to just lower the price
)

db.products.findOne({ name: "Shoe" })   // what comes back?

db.products.updateOne(
  { name: "Shoe" },
  { $set: { price: 1999 } }
)

// now findOne({ name: "Shoe" }) returns:
// { _id: …, name: "Shoe", price: 1999, color: "red" }