Jak zaprojektować schematy w MongoDB?

Question

Accepted Answer

Projektowanie schematów MongoDB opiera się na kluczowej decyzji: **embedding** (przechowywanie powiązanych danych wewnątrz dokumentu) vs **referencing** (przechowywanie powiązanych danych w oddzielnych dokumentach/kolekcjach z referencjami). W przeciwieństwie do SQL-u, który domyślnie normalizuje dane, projektowanie MongoDB optymalizuje sposób *dostępu* do danych.

## Embedding — przechowywanie powiązanych danych razem

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**Embedding** utrzymuje powiązane dane w jednym dokumencie — odczytaj wszystko w jednym zapytaniu (szybko, bez joinów). Dobry dla danych dostępnych razem i relacji "zawiera".

## Referencing — łączenie oddzielnych dokumentów

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**Referencing** przechowuje dane oddzielnie i łączy je za pomocą id (jak klucz obcy) — zapytaj oddzielnie lub połącz za pomocą `$lookup`.

## Kiedy użyć embedding vs reference

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## Projektuj dla wzorców dostępu (zasada kluczowa)

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## Dlaczego to ważne

Projektowanie schematów jest krytycznie ważne w MongoDB — różni się od SQL i jest prawdopodobnie bardziej konsekwencyjne niż w SQL, ponieważ elastyczny model dokumentów MongoDB daje Ci wybory, które znacząco wpływają na wydajność i łatwość utrzymania, dlatego zrozumienie tego jest niezbędne do budowania efektywnych aplikacji MongoDB.

Centralna decyzja — **embedding vs referencing** — jest definiującą decyzją projektową MongoDB: **embedding** (przechowywanie powiązanych danych w dokumencie) umożliwia szybkie odczyty powiązanych danych w jednym zapytaniu (bez joinów) i pasuje do danych dostępnych razem i relacji "zawiera", podczas gdy **referencing** (łączenie oddzielnych dokumentów za pomocą id) pasuje do dużych/nieograniczonych danych, niezależnie dostępnych danych i relacji udostępnianych/wielu.

Zrozumienie **kiedy użyć każdego** (osadzaj dla ograniczonych, razem dostępnych, posiadanych danych; referuj dla dużych/rosnących, niezależnych, udostępnianych lub wielu relacji — i pamiętając o limicie 16MB rozmiaru dokumentu MongoDB) jest kluczową umiejętnością.

Co najważniejsze, zrozumienie zasady przewodniej — **projektuj dla wzorców dostępu** (strukturyzuj dane wokół *tego, jak je zapytywasz*, aby typowe zapytania były efektywne, często odczyt jednego dokumentu, zamiast normalizacji domyślnie jak SQL) — to to, co wyróżnia dobre projektowanie schematów MongoDB.

Może to oznaczać zaakceptowanie pewnej **denormalizacji** (duplikacji) dla efektywności odczytu, kompromisu wobec złożoności aktualizacji, który jest akceptowalny i często słuszny w MongoDB.

Ponieważ projektowanie schematów profundowo wpływa na wydajność i łatwość utrzymania aplikacji MongoDB (zła decyzja embedding/reference powoduje wolne zapytania, ogromne dokumenty lub złożoność aktualizacji), a ponieważ podejście sterowane wzorcami dostępu, embedding vs referencing jest fundamentalnie różne od normalizacji SQL, zrozumienie projektowania schematów MongoDB — decyzji embedding/reference, kiedy użyć każdego i projektowania dla wzorców dostępu — jest niezbędne, cenną wiedzą do budowania efektywnych aplikacji MongoDB, jeden z najważniejszych i najbardziej charakterystycznych tematów MongoDB, który odróżnia tych, którzy projektują dobre schematy dokumentów od tych, którzy naiwnie przenoszą projekty relacyjne.