MongoDB'de şemaları nasıl tasarlarsınız?

Question

Accepted Answer

MongoDB şema tasarımı bir ana karar etrafında döner: **embedding** (ilişkili verileri bir belgenin içinde depolamak) vs **referencing** (ilişkili verileri ayrı belgeler/koleksiyonlarda depolamak ve referanslar kullanmak). SQL'in varsayılan normalizasyonundan farklı olarak, MongoDB tasarımı verilerin *nasıl erişildiğini* optimize eder.

## Embedding — ilişkili verileri bir arada depolayın

```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** ilişkili verileri tek bir belgede tutar — hepsi tek bir sorguyla okuyun (hızlı, join yok). Birlikte erişilen veriler ve "içerir" ilişkileri için iyidir.

## Referencing — ayrı belgeleri bağlayın

```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** verileri ayrı tutar ve id ile bağlar (yabancı anahtar gibi) — ayrı sorgula veya `$lookup` ile birleştir.

## Ne zaman embed vs reference kullanılacak

```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)
```

## Erişim desenleri için tasarla (temel ilke)

```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.
```

## Neden önemli

MongoDB'de şema tasarımı çok önemlidir — SQL'deki gibi değildir ve tartışılabilir şekilde daha sonuç doğurucu bir karardır, çünkü MongoDB'nin esnek belge modeli performans ve bakımlanabilirliği önemli ölçüde etkileyen seçimler sunar, bu nedenle bunu anlamak etkili MongoDB uygulamaları oluşturmak için gereklidir.

Merkezi karar — **embedding vs referencing** — belirleyici MongoDB tasarım seçimidir: **embedding** (ilişkili verileri bir belgenin içinde depolamak) ilişkili verilerin hızlı tek-sorgu okumalarını (join yok) sağlar ve birlikte erişilen ve "içerir" ilişkilerine uyar, **referencing** (ayrı belgeleri id ile bağlamak) ise büyük/sınırsız veriler, bağımsız erişilen veriler ve paylaşılan/çok-sayıda ilişkilere uyar.

Her birinin **ne zaman kullanılacağını anlamak** (bounded, birlikte erişilen, sahip olunan veriler için embed et; büyük/büyüyen, bağımsız, paylaşılan veya çok-sayıda ilişkiler için reference et — ve MongoDB'nin 16MB belge boyut sınırını göz önünde bulundur) anahtar beceridir.

En önemlisi, rehber ilkeyi anlamak — **erişim desenleri için tasarla** (verileri *nasıl sorgulayacağınızı* göz önünde bulundurarak yapılandır, böylece yaygın sorgular verimli olsun, sık sık tek bir belge okuma, SQL gibi varsayılan olarak normalize etmek yerine) — MongoDB şema tasarımını ayırt eden şeydir.

Bu, okuma verimliliği için **denormalizasyonu** (tekrar) kabul etmek anlamına gelebilir; güncelleme karmaşıklığına karşı bir takas bu MongoDB'de kabul edilebilir ve sık sık doğru olur.

Şema tasarımı MongoDB uygulama performansını ve bakımlanabilirliğini derinden etkilediği için (kötü bir embedding/referencing seçimi yavaş sorgulara, muazzam belgelere veya güncelleme karmaşıklığına neden olur) ve erişim-desen-odaklı, embed-vs-reference yaklaşımı SQL normalizasyonundan temel olarak farklı olduğu için, MongoDB şema tasarımını anlamak — embed/reference kararı, her birinin ne zaman kullanılacağı ve erişim desenleri için tasarlama — etkili MongoDB uygulamaları oluşturmak için gerekli, yüksek değerli bilgidir; iyi belge şemaları tasarlayan ile ilişkisel tasarımları naif şekilde taşıyan olanları ayıran, en önemli ve ayırt edici MongoDB konularından biridir.