Hızla değişen veri modelleri için neden belge veritabanlarının uygun olduğunu öğrenin: esnek şemalar, daha kolay yineleme, doğal JSON depolama ve planlamanız gereken takaslar.
Bir belge veritabanı, veriyi genellikle JSON benzeri bir formatta kendi içinde bütün "belgeler" olarak saklar. Bir iş nesnesini birden fazla tabloya yaymak yerine tek bir belge, alanları, alt alanları ve dizileriyle birlikte o nesne hakkında her şeyi barındırabilir—kodda birçok uygulamanın zaten veriyi gösterdiği şekilde.
users koleksiyonu veya orders koleksiyonu).Aynı koleksiyondaki belgelerin aynı görünmesi gerekmez. Bir kullanıcı belgesi 12 alan içerebilir, başka bir tanesi 18 alan; her ikisi de yan yana durabilir.
Bir kullanıcı profili hayal edin. Başlangıçta name ve email ile başlarsınız. Ertesi ay pazarlama preferred_language ister. Sonra müşteri başarı ekibi timezone ve subscription_status ister. Daha sonra social_links (bir dizi) ve privacy_settings (iç içe bir nesne) eklersiniz.
Bir belge veritabanında genellikle yeni alanları hemen yazmaya başlayabilirsiniz. Eski belgeler olduğu gibi kalabilir; geri doldurmayı (backfill) yapmak isteyene kadar dokunmayabilirsiniz.
Bu esneklik ürün çalışmalarını hızlandırabilir, fakat sorumluluğu uygulamanıza ve ekibinize kaydırır: dağınık veya tutarsız veri oluşmaması için net konvansiyonlara, isteğe bağlı doğrulama kurallarına ve düşünülmüş sorgu tasarımına ihtiyaç duyarsınız.
Sonraki bölümlerde hangi modellerin neden sık değiştiğine, esnek şemaların pürüzleri nasıl azalttığına, belgelerin gerçek uygulama sorgularına nasıl uyduğuna ve belge depolamayı ilişkisel veritabanına tercih etmeden veya hibrit yaklaşım kullanmadan önce hangi takasların göz önünde bulundurulması gerektiğine bakacağız.
Veri modelleri nadiren durağandır çünkü ürün nadiren durağandır. "Sadece bir kullanıcı profili sakla" diye başlayan şey hızla tercihler, bildirimler, faturalama meta verileri, cihaz bilgileri, onay bayrakları ve ilk versiyonda olmayan bir düzine başka detaya dönüşür.
Çoğu model değişimi aslında öğrenmenin sonucudur. Ekipler alan eklerken:
Bu değişiklikler genellikle artçı ve sık olur—küçük eklemeler ki bunları resmi "büyük göç" olarak planlamak zordur.
Gerçek veritabanları geçmiş içerir. Eski kayıtlar yazıldıkları şekliyle kalır, yeni kayıtlar en son şekli benimser. marketing_opt_in yokken oluşturulmuş müşterileriniz, delivery_instructions desteklenmeden önce oluşturulmuş siparişleriniz veya yeni source alanı tanımlanmadan önce loglanmış etkinlikleriniz olabilir.
Yani “tek bir modeli” değiştirmiyorsunuz—aynı anda birden fazla versiyonu destekliyorsunuz, bazen aylar boyunca.
Birden çok ekip paralel olarak yayımladığında, veri modeli paylaşılan bir yüzey alanı olur. Ödeme ekibi dolandırıcılık sinyalleri eklerken, büyüme ekibi atıf verileri ekleyebilir. Mikroservislerde her servis "müşteri" kavramını farklı ihtiyaçlarla saklayabilir ve bu ihtiyaçlar bağımsız olarak evrilebilir.
Koordinasyon yoksa “mükemmel tek şema” bir darboğaz olur.
Harici sistemler genellikle kısmen bilinen, iç içe veya tutarsız yükler gönderir: webhook olayları, partner meta verileri, form gönderimleri, cihaz telemetri verileri. Önemli parçaları normalleştirseniz bile, denetim, hata ayıklama veya gelecekteki kullanım için orijinal yapıyı tutmak isteyebilirsiniz.
Tüm bu güçler, özellikle gönderim hızı önemliyse, değişime tolerans gösteren depolamaya yönlendirir.
Bir ürün şeklini bulurken veri modeli nadiren "tamamlanmıştır." Yeni alanlar ortaya çıkar, eskileri isteğe bağlı olur ve farklı müşteriler biraz farklı bilgiler isteyebilir. Belge veritabanları bu anlarda popülerdir çünkü her değişikliği bir veritabanı göçü projesine dönüştürmek zorunda bırakmadan veriyi evriltmenize izin verirler.
JSON belgelerle yeni bir özellik eklemek genellikle yeni kayıtlara o alanı yazmak kadar basittir. Mevcut belgeler dokunulmamış kalabilir, ta ki siz backfill yapmaya karar verene dek. Bu, yeni bir tercih toplama deneyinin öğrenmeye başlaması için şema değişikliği, dağıtım penceresi ve backfill işi koordine etmeyi gerektirmediği anlamına gelir.
Bazen gerçekten varyantlarınız olur: "ücretsiz" hesap daha az ayara sahiptir, "kurumsal" hesap ekstra alanlar gerektirir veya bir ürün tipi ekstra niteliklere ihtiyaç duyar. Belge veritabanında, uygulamanız bunları nasıl yorumlayacağını biliyorsa aynı koleksiyonda farklı şekiller kabul edilebilir.
Bunun yerine her şeyi tek bir katı yapıya zorlamak, şunları korumanıza izin verir:
id, userId, createdAt) tutarlı tutunEsnek şema "kural yok" demek değildir. Yaygın bir desen, eksik alanları "varsayılan kullan" diye ele almaktır. Uygulamanız okuma zamanında mantıklı varsayılanlar uygulayabilir (veya yazma zamanında onları ayarlayabilir), böylece eski belgeler de doğru davranır.
Feature flagler geçici alanlar ve kısmi dağıtımlar getirebilir. Esnek şemalar, bir değişikliği küçük bir kohorta göndermeyi, ek durumu yalnızca işaretli kullanıcılar için saklamayı ve şemaya takılmadan hızla yinelemeyi kolaylaştırır.
Birçok ürün ekibi doğal olarak "kullanıcının ekranda gördüğü şey" kavramına göre düşünür. Bir profil sayfası, bir sipariş detay görünümü, bir proje panosu—her biri genellikle tek bir uygulama nesnesiyle eşleşir. Belge veritabanları bu zihinsel modeli destekler: o nesneyi tek bir JSON belgesi olarak saklamanıza izin vererek uygulama kodu ile depolama arasındaki çevirileri azaltır.
İlişkisel tablolarda aynı özellik genellikle birden çok tabloya, yabancı anahtarlara ve join mantığına bölünür. Bu yapı güçlüdür ama uygulama veriyi zaten iç içe bir nesne olarak tuttuğunda ekstra bir seremoni gibi gelebilir.
Bir belge veritabanında nesneyi neredeyse olduğu gibi saklayabilirsiniz:
User sınıf/typenizle eşleşen bir user belgesiProject durum modelinizle eşleşen bir project belgesiDaha az çeviri genellikle daha az eşleme hatası ve alanlar değiştiğinde daha hızlı yineleme demektir.
Gerçek uygulama verisi nadiren düz olur. Adresler, tercihler, bildirim ayarları, kaydedilmiş filtreler, UI bayrakları—bunların hepsi doğal olarak iç içedir.
Alt nesneleri üst belgenin içinde tutmak ilişkili değerleri yakın tutar; bu da "bir kayıt = bir ekran" sorguları için yararlıdır: tek bir belge getir, tek bir görünüm render et. Bu, join ihtiyacını ve onlarla gelen performans sürprizlerini azaltabilir.
Her özellik ekibi belgelerinin şeklini sahiplendiğinde sorumluluklar daha net olur: özelliği gönderen ekip aynı zamanda verisini de evrimleştirir. Bu, bağımsız değişikliklerin istisna değil kural olduğu mikroservis veya modüler mimarilerde iyi çalışır.
Belge veritabanları sık gönderen ekiplerle iyi uyum sağlar çünkü küçük veri eklemeleri genellikle koordine "dünya durdurma" veritabanı değişikliği gerektirmez.
Bir ürün yöneticisi "sadece bir alan daha" isterse (ör. preferredLanguage veya marketingConsentSource), belge modeli genellikle o alanı hemen yazmaya başlamanıza izin verir. Her zaman bir göç planlamanız, tabloları kilitlemeniz veya birden çok serviste yayın penceresi ayarlamanız gerekmez.
Bu, sprinti engelleyebilecek görevlerin sayısını azaltır: uygulama evrilirken veritabanı kullanılabilir kalır.
JSON-benzeri belgelere isteğe bağlı alanlar eklemek genellikle geriye dönük uyumludur:
Bu desen dağıtımları daha sakin hale getirir: önce yazma yolunu yayınlayabilir (yeni alanı depolamaya başlayabilirsiniz), sonra okuma yollarını ve UI’yı güncellersiniz—her mevcut belgeyi hemen güncellemek zorunda kalmadan.
Gerçek sistemler nadiren tüm istemcileri aynı anda yükseltir. Şunlar olabilir:
Belge veritabanlarında ekipler genellikle alanları ekleyici ve isteğe bağlı olarak ele alacak şekilde tasarlar. Yeni yazanlar veri ekleyebilir, eski okuyanları bozmaz.
Pratik bir dağıtım deseni şu şekildedir:
Bu yaklaşım koordinasyon maliyetlerini azaltırken hızı yüksek tutar.
Ekiplerin belge veritabanlarını sevmesinin bir nedeni, veriyi uygulamanızın çoğunlukla nasıl okuduğunu düşünerek modelleyebilmenizdir. Bir kavramı birçok tabloya yaymak ve sonra tekrar birleştirmek yerine "tüm" nesneyi (çoğunlukla JSON belgeleri olarak) tek bir yerde saklayabilirsiniz.
Denormalizasyon, ortak sorguların tek bir belge okumasıyla cevaplanabilmesi için ilgili alanları çoğaltmak veya gömmek anlamına gelir.
Örneğin bir sipariş belgesi müşteri anlık görüntü alanlarını (satın alma anındaki isim, e-posta) ve satır öğelerinin gömülü bir dizisini içerebilir. Bu tasarım "son 10 siparişimi göster" gibi işleri hızlı ve basit yapar çünkü UI sayfayı render etmek için birden çok sorgu yapmak zorunda kalmaz.
Bir ekran veya API yanıtı için gereken veri tek belgede yaşadığında genellikle elde edersiniz:
Bu, özellikle ürün akışları, profiller, sepetler ve panolar gibi okuma-ağırlıklı yollar için gecikmeyi azaltma eğilimindedir.
Gömme genellikle faydalıdır khi:
Referanslama genellikle daha iyidir khi:
Evrensel olarak “en iyi” belge şekli yoktur. Bir sorgu için optimize edilmiş model başka bir sorguyu yavaşlatabilir (veya güncellemesi daha pahalı hale getirebilir). En güvenilir yaklaşım gerçek sorgularınızdan başlamak—uygulamanızın gerçekten neleri getirdiği—ve belgeleri bu okuma yolları etrafında şekillendirmek, sonra kullanım evrildikçe modeli yeniden değerlendirmektir.
Okurken şema, depolamadan önce her alanı ve tablo şeklini tanımlamak zorunda olmadığınız anlamına gelir. Bunun yerine uygulamanız (veya analiz sorgunuz) her belgeyi okuduğunda yapıyı yorumlar. Pratikte, bu preferredPronouns veya iç içe shipping.instructions gibi yeni bir alanı şema göçü koordine etmeden eklemenize izin verir.
Çoğu ekip yine de bir "beklenen şekle" sahiptir—sadece uygulama veya analitik okuma zamanında daha seçici olarak zorlar. Bir müşteri belgesinde phone olabilir ya da olmayabilir. Eski bir siparişte discountCode bir string olarak saklanmışken, yeniler daha zengin bir discount nesnesi saklayabilir.
Esneklik kaos demek zorunda değil. Yaygın yaklaşımlar:
id, createdAt veya status gibi kilit alanları zorunlu kılın ve yüksek riskli alanların türlerini sınırlayın.Biraz tutarlılık çok şey kazandırır:
camelCase, zaman damgaları ISO-8601)schemaVersion: 3) ki okuyucular eski ve yeni şekilleri güvenle ele alabilsinModel stabil hale geldiğinde—genelde hangi alanların gerçekten çekirdek olduğu öğrenildikten sonra—kritik alanlar ve ilişkiler etrafında daha katı doğrulama getirin. Deneysel veya isteğe bağlı alanları esnek bırakın, böylece veritabanı sürekli göçlerle değil hızlı yinelemeyle çalışmaya devam eder.
Ürün haftalık değişiyorsa sadece “şimdiki” veri şekli önemli değildir; veriye nasıl geldiğinizin güvenilir bir hikayesi de gerekir. Belge veritabanları, kendi içinde bütün kayıtlar sakladıkları ve geçmişi yeniden yazmayı zorunlu kılmadıkları için değişim geçmişini tutmak üzere doğal olarak uygundur.
Yaygın bir yaklaşım değişiklikleri bir etkinlik akışı olarak saklamaktır: her etkinlik yeni bir belge olarak eklenir (eski satırları güncellemek yerine). Örneğin: UserEmailChanged, PlanUpgraded veya AddressAdded.
Her etkinlik kendi JSON belgesi olduğu için o andaki tam bağlamı yakalayabilirsiniz—bunu kim yaptı, ne tetikledi ve daha sonra ihtiyaç duyacağınız meta veriler neler.
Etkinlik tanımları nadiren sabit kalır. source="mobile", experimentVariant veya paymentRiskSignals gibi yeni alanlar ekleyebilirsiniz. Belge depolamada eski etkinlikler bu alanları atlayabilir; yeni etkinlikler ise bunları içerebilir.
Okuyucular eksik alanları güvenle varsayabilir; milyonlarca tarihsel kaydı göç ettirip yeniden yazmak zorunda kalmadan yeni bir nitelik ekleyebilirsiniz.
Tüketicileri tahmin edilebilir tutmak için pek çok ekip her belgeye bir schemaVersion (veya eventVersion) alanı ekler. Bu kademeli dağıtıma izin verir:
Ne olduğunu gösteren dayanıklı bir geçmiş denetimler dışında da faydalıdır. Analitik ekipleri herhangi bir zamanda durumu yeniden oluşturabilir; destek mühendisleri hatalara yol açan yükü yeniden oynatarak veya tam yükü inceleyerek kök neden analizini hızlandırabilir. Aylar içinde bu, raporlamayı ve hata ayıklamayı daha güvenilir kılar.
Belge veritabanları değişimi kolaylaştırır, ama tasarım işini ortadan kaldırmaz—sadece onu farklı yere kaydırır. Karar vermeden önce hangi faydaları es geçtiğinizi netleştirmek faydalıdır.
Çoğu belge veritabanı işlemleri destekler, ama çoklu belge (multi-entity) işlemler sınırlı, daha yavaş veya ilişkisel bir veritabanına göre daha maliyetli olabilir—özellikle yüksek ölçekte. Temel iş akışınız birkaç kaydı "tümünü ya hiç" şeklinde güncellemeyi gerektiriyorsa (ör. bir sipariş, envanter ve muhasebe kaydını birlikte güncellemek), veritabanınızın bunu nasıl ele aldığını ve performans veya karmaşıklık maliyetini kontrol edin.
Alanlar isteğe bağlı olduğu için ekipler üretimde aynı kavramın birkaç "versiyonunu" yanlışlıkla yaratabilir (address.zip vs address.postalCode gibi). Bu, downstream özellikleri bozabilir ve hataları takip etmeyi zorlaştırır. Pratik bir hafifletme yöntemi, ana belge tipleri için paylaşılan bir sözleşme tanımlamak ve kritik yerlerde isteğe bağlı doğrulama kuralları eklemektir—örneğin ödeme durumu, fiyatlama veya izinler.
Belgeler serbestçe evrilirse analistler çoklu alan adları ve eksik değerler için mantık yazmak zorunda kalır. Ağır raporlama yapan ekipler için bir plan gerekebilir:
Siparişlerin içine müşteri snapshot’ı gömmek okuma hızını artırır ama bilgiyi çoğaltır. Ortak bir veri değiştiğinde her yerde güncelleme yapmak, geçmişi saklamak veya geçici tutarsızlığa tahammül etmek arasında karar vermeniz gerekir. Bu karar kasıtlı olmalı; aksi halde hafif veri sapması riski doğar.
Belge veritabanları değişiklik sık olduğunda mükemmeldir, ama modelleme, adlandırma ve doğrulamayı sürekli ürün işi olarak ele alan takımları ödüllendirir—bir kerelik ayar değil.
Belge veritabanları veriyi JSON belgeleri olarak sakladıkları için alanların isteğe bağlı olduğu, sık değiştiği veya müşteri/cihaz/ürün hattına göre farklılık gösterdiği durumlarda doğal bir uyum sağlar. Her kaydı aynı katı tablo şekline zorlamak yerine veri modelini kademeli olarak evriltirken ekipleri hareket halinde tutabilirsiniz.
Ürün verisi nadiren sabittir: yeni bedenler, malzemeler, uyumluluk bayrakları, paketler, bölgesel açıklamalar ve pazar yerine özgü alanlar sürekli ortaya çıkar. JSON içindeki iç içe verilerle bir "ürün" çekirdek alanları (SKU, fiyat) tutarken kategoriye özel nitelikleri haftalar süren şema yeniden tasarımına gerek kalmadan saklayabilir.
Profiller genellikle küçük başlar ve büyür: bildirim ayarları, pazarlama rızaları, onboarding cevapları, feature flagler ve kişiselleştirme sinyalleri. Belge veritabanında kullanıcılar farklı alan setlerine sahip olabilir; bu mevcut okumaları bozmaz. Bu şema esnekliği ayrıca deneylerin alanları hızlıca ekleyip kaldırdığı çevik geliştirmeye de yardımcı olur.
Modern CMS içeriği sadece "bir sayfa" değildir. Hero bölümleri, SSS’ler, ürün karuselleri, embed’ler gibi bloklar ve bileşenlerin karışımıdır—her biri kendi yapısına sahiptir. Sayfaları JSON belgeleri olarak saklamak editörlerin ve geliştiricilerin yeni bileşen tipleri tanıtmasına, tarihsel tüm sayfaları derhal göç ettirmeden izin verir.
Telemetri genellikle firmware sürümüne, sensör paketine veya üreticiye göre değişir. Belge veritabanları bu evrilen veri modellerini iyi idare eder: her olay cihazın bildiği bilgileri içerebilir, okurken şema analitik araçlar alanları mevcut olduğunda yorumlayabilir.
NoSQL ile SQL arasında karar verirken, belge veritabanlarının bu senaryolarda daha az sürtünme ile daha hızlı yineleme sunduğunu görürsünüz.
Veri modeliniz hâlâ otururken "kaçırtılabilir ve kolay değişen" olmak kağıt üzerindeki mükemmellikten iyidir. Bu pratik alışkanlıklar veritabanınızı bir çöplüğe çevirmeden hızınızı korumanıza yardımcı olur.
Her özelliğe, üretimde beklediğiniz en önemli okuma ve yazmaları yazarak başlayın: render ettiğiniz ekranlar, döndürdüğünüz API yanıtları ve sık yapılan güncellemeler.
Bir kullanıcı eylemi düzenli olarak “sipariş + öğeler + gönderi adresi” gerektiriyorsa, bu okuma için minimal ek fetching ile hizmet verebilecek bir belge modelleyin. Başka bir eylem "duruma göre tüm siparişleri" istiyorsa sorgulayabileceğiniz veya dizinleyebileceğiniz bir yol olduğundan emin olun.
Gömme (nesting) veri üst belgesiyle birlikte okunuyorsa ve boyutu sınırlıysa harikadır.
Referanslama, çocuk koleksiyonun büyük veya sınırsız olabileceği, çocuğun birçok ebeveyn tarafından paylaşıldığı veya sık değiştiği durumlarda daha güvenlidir.
Her ikisini de karıştırabilirsiniz: okuma hızı için snapshot gömün, güncellemeler için ise gerçeğin kaynağına referans bırakın.
Şema esnek olsa da, bağımlı olduğunuz alanlar için hafif kurallar ekleyin (türler, zorunlu ID’ler, izin verilen durumlar). Okuyucuların eski belgeleri güvenle ele alabilmesi için bir schemaVersion veya docVersion alanı ekleyin ve zaman içinde göç ettirin.
Göçleri tek seferlik bir olay değil periyodik bakım olarak ele alın. Model olgunlaştıkça küçük backfill ve temizlik işleri (kullanılmayan alanlar, yeniden adlandırılan anahtarlar, denormalize snapshot’lar) planlayın ve etkisini ölçün. Basit bir kontrol listesi ve hafif bir göç betiği çok işe yarar.
Belge veritabanı ile ilişkisel veritabanı arasında seçim yapmak "hangisi daha iyi" meselesi değil, ürününüzün en çok hangi tür değişiklikleri yaşadığı meselesidir.
Veri şeklinin sık değiştiği, farklı kayıtların farklı alanlara sahip olabileceği veya ekiplerin her sprintte şema göçü koordine etmeden özellik göndermesi gerektiği durumlarda belge veritabanları güçlü bir uyum sağlar.
Ayrıca uygulamanız bir sipariş (müşteri bilgisi + öğeler + teslim notları) veya bir kullanıcı profili (ayarlar + tercihler + cihaz bilgisi) gibi "tüm nesneler" ile doğal olarak çalışıyorsa belge modeli uygundur.
İlişkisel veritabanları şu durumlarda öne çıkar:
Ekip işinin çoğu çapraz tablo sorguları ve analitik optimizasyona odaklıysa, uzun vadede SQL genellikle daha basit bir evdir.
Birçok ekip ikisini birden kullanır: ilişkisel veritabanını “çekirdek kayıt sistemi” için (faturalama, envanter, haklar) ve belge deposunu hızlı evrilen veya okuma-odaklı görünümler için (profiller, içerik meta verisi, ürün katalogları). Mikroservislerde bu doğal olarak hizalanabilir: her servis sınırlarıyla uyumlu depolama modelini seçer.
Hibrit, ilişkisel bir veritabanının içinde de var olabilir. Örneğin PostgreSQL JSON/JSONB kullanarak yarı-yapılandırılmış alanlar saklayabilir—işlemsel tutarlılık ve evrilen nitelikler için güvenli bir yer istediğinizde faydalıdır.
Şemanız haftalık değişiyorsa darboğaz genellikle uçtan uca döngüdür: modelleri, API’leri, UI’yı güncelleme, göçler (varsa) ve değişiklikleri güvenle yayımlama. Koder.ai bu tür yineleme için tasarlanmıştır. Özelliği ve veri şeklini sohbette tarif edebilir, çalışan web/backend/mobile uygulama kodu üretebilir ve gereksinimler evrildikçe bunu rafine edebilirsiniz.
Uygulamada ekipler genellikle ilişkisel bir çekirdek ile başlar (Koder.ai’in backend yığını Go ve PostgreSQL’dir) ve esnek öznitelikler veya etkinlik yükleri için belge-benzeri desenler kullanırlar (ör. JSONB). Koder.ai’in anlık görüntüleri ve geri alma özellikleri, deneysel bir veri şeklinin hızlıca geri alınması gerektiğinde yardımcı olur.
Karar vermeden önce kısa bir değerlendirme yapın:
Seçenekleri karşılaştırıyorsanız kapsamı dar ve süreyi sınırlı tutun—daha az sürprizle hangi modelin sizi daha hızlı gönderdiğini görün. Daha fazlası için bkz. /blog/document-vs-relational-checklist.
Bir belge veritabanı her kaydı içiçe nesneler ve diziler de içerebilen JSON-benzeri, kendi içinde bütün bir belge olarak saklar. Tek bir iş nesnesini birden fazla tabloya bölmek yerine genellikle tüm nesneyi tek seferde okur ve yazar (örneğin users, orders koleksiyonları içinde).
Hızla değişen ürünlerde yeni alanlar sürekli ortaya çıkar (tercihler, faturalama verileri, onay bayrakları, deney alanları). Esnek şemalar yeni alanları hemen yazmanıza, eski belgeleri olduğu gibi bırakmanıza ve gerekirse daha sonra tamamlamanıza (backfill) izin verir—böylece küçük değişiklikler büyük göç (migration) projelerine dönüşmez.
Mutlaka hayır. Çoğu ekip hâlâ bir “beklenen şekle” sahiptir; ancak uygulama ve altyapı üzerinden uygulanma zamanı kayar. Yaygın yaklaşımlar:
Bu, esnekliği korurken dağınık ve tutarsız belgelerin önüne geçer.
Yeni alanları ekleyip eski verileri bozmadan ilerleyin:
Bu, karışık veri sürümlerinin üretimde kesinti olmadan var olmasını sağlar.
En sık yapılan okumalara göre modelleyin: bir ekran veya API yanıtı “sipariş + ürünler + teslimat adresi” istiyorsa, bu verileri tek bir belgede tutmak pratik olabilir. Bu, uygulama ile veritabanı arasında gidiş gelişleri azaltıp, join ağırlıklı bir birleştirmeyi önleyerek okuma yolundaki gecikmeyi düşürebilir.
Çocuğu gömülü (embed) tutmak genellikle şu durumlarda iyidir:
Referans kullanmak daha iyidir:
Ayrıca ikisini birleştirebilirsiniz: hızlı okumalar için bir snapshot gömün, güncellemeler için ise kaynağa referans verin.
Yeni bir alan eklemeyi daha geriye dönük uyumlu hale getirir:
Bu, birden çok servis veya eski sürümlerdeki mobil istemciler varken özellikle yararlıdır.
Hafif koruyucu önlemler ekleyin:
id, createdAt, )Eklenti-temelli (append-only) etkinlik belgeleri saklamak yaygın bir yaklaşımdır: her değişiklik yeni bir belge olarak eklenir (UserEmailChanged, PlanUpgraded, AddressAdded). Bu belgeler bağlamı o anki haliyle yakalar—kim, ne tetikledi, hangi meta veriler var—ve geçmişi yeniden yazmadan yeni alanlar eklemeye izin verir.
Dikkate alınması gereken başlıca takaslar şunlardır:
Çoğu ekip hibrit bir yaklaşım benimser: kesin “kayıt sistemi” için ilişkisel veritabanı; hızlı değişen veya okuma-odaklı modeller için belge deposu.
statuscamelCase, ISO-8601 zaman damgaları)schemaVersion/docVersion alanıBu adımlar address.zip ile address.postalCode gibi sürüklenmeleri önlemeye yardımcı olur.