MongoDB’de normalizasyonun adı değişir
İlişkisel veritabanında müşteri ve sipariş ayrı tablolarda durur. MongoDB’de aynı bilgiyi sipariş dokümanının içine gömebilir veya customerId ile ayrı customers koleksiyonuna referans verebilirsiniz.
Bu kararın tek cevabı yoktur. Sipariş geçmişinde müşterinin o günkü adını göstermek istiyorsanız kopya alan doğru olabilir. Güncel müşteri e-postasını her zaman tek yerden okumak istiyorsanız referans daha güvenlidir.
- Embed: birlikte okunan, aynı yaşam döngüsüne sahip veri için uygundur.
- Reference: bağımsız değişen ve birçok yerde kullanılan veri için daha güvenlidir.
- Kopya alan: tarihsel kayıt veya okuma performansı için bilinçli kullanılabilir.
- Büyüyen array: doküman boyutu ve güncelleme maliyeti açısından izlenmelidir.
Embed örneği: sipariş satırları
Sipariş ve sipariş satırları çoğu sistemde birlikte okunur. Sipariş satırının yaşam döngüsü de siparişe bağlıdır. Bu yüzden MongoDB’de order_items benzeri ayrı koleksiyon yerine satırları sipariş dokümanına gömmek çoğu zaman mantıklıdır.
Ama ürünün güncel adını her siparişte otomatik değiştirmek istemeyebilirsiniz. Sipariş anındaki ürün adı tarihsel kayıt olabilir. Bu durumda productNameSnapshot gibi bir kopya alan bilinçli bir denormalizasyondur.
Sipariş dokümanı örneği
{
"_id": "ord_123",
"customerId": "cus_42",
"customerEmailSnapshot": "[email protected]",
"status": "paid",
"items": [
{
"productId": "prd_9",
"productNameSnapshot": "Kırmızı Defter",
"quantity": 2,
"unitPriceCents": 12900
}
],
"createdAt": "2026-06-14T12:30:00Z"
}Reference örneği: sık değişen müşteri profili
Müşteri profili, adres listesi, abonelik durumu veya risk skoru sık değişiyorsa bunları her siparişe kopyalamak sorun üretir. Bir değişiklik birçok dokümana yayılmak zorunda kalır.
Bu durumda referans daha güvenlidir. Sipariş customerId taşır; güncel profil gerektiğinde customers koleksiyonundan okunur. Eğer çok sık birlikte okunuyorsa küçük bir özet alan kopyalanabilir ama kopyanın amacı yazılmalıdır.
Referanslı model örneği
// orders
{
"_id": "ord_123",
"customerId": "cus_42",
"status": "paid"
}
// customers
{
"_id": "cus_42",
"email": "[email protected]",
"name": "Ayşe Yılmaz",
"riskLevel": "low"
}Kararı sorgu deseni verir
MongoDB’de modelleme yaparken önce ekranları ve sorguları düşünün. Veri çoğu zaman tek doküman olarak mı okunuyor, yoksa farklı ekranlarda farklı parçalar mı gerekiyor? Güncelleme sıklığı okuma sıklığından yüksek mi?
Cevaplar değiştikçe model de değişebilir. MongoDB şemasız gibi görünür ama bu şema yok demek değildir; şema uygulama kodunda ve kullanım deseninde yaşar.
Embed/reference karar notu
Veri birlikte mi okunuyor? Birlikte mi güncelleniyor? Liste sınırsız büyüyebilir mi? Kopya alan tarihsel kayıt mı, güncel bilgi mi? Tutarsızlık olursa kullanıcı ne görür? İndeks ihtiyacı ne? Geriye dönük migration gerekir mi?