Veri modeli tasarimi ve avantajlari (versiyonlama, zaman damgalari, sahiplik)

[devburak]

Merhaba ekip,

Bu tartismada contextHub projesi icin planladigimiz veri modeli ve bunun avantajlarini ayrintili olarak paylasiyoruz. Amacimiz WordPress benzeri ancak cok daha esnek, olceklenebilir ve optimize bir yapi sunmak.

Oz

et model

• Multi-tenant: Tum koleksiyonlarda tenantId alani var. tenants ve domains koleksiyonlari kiraci ve alan adlarini temsil eder.
• Yetkilendirme ve kullanicilar: users ve memberships ile rol bazli erisim. Her membership dokumaninda roles, createdAt, updatedAt, createdBy, updatedBy alanlariyla kayit sahibi ve tarihcesi tutulur.
• Icerik tipleri ve kayitlar: contentTypes koleksiyonunda icerik tipleri (Page, Post, Campaign vb.) tanimlanir. Her icerik kaydi entries koleksiyonunda saklanir. Kayitlarda taslak (lexical, htmlCachedDraft) ve yayinlanmis (published.lexical, published.htmlCached) surumler bulunur. Istege bagli esnek alanlar icin meta objesi vardir.
• Taxonomies ve terms: Kategoriler, etiketler ve diger hiyerarsik/duz terimler icin taxonomies ve terms.
• Navigasyon: navigation koleksiyonu menuler ve site haritasini tutar.
• Medya: R2/S3 uzerinde saklanan dosyalarin meta verisi media koleksiyonunda; varyantlar (thumb, webp vb.) listelenebilir.
• Formlar ve cevaplar: forms (alanlar, dogrulama, tetikleyiciler) ve formResponses (gelen veriler, metadata) koleksiyonlari vardir.
• Analitik: events ve gunluk agregasyon dailyAgg koleksiyonlari ile basit ziyaret & custom event takibi.
• Commerce ve ozel koleksiyonlar: Basit urun/market yapisi ve JSON sema tabanli esnek koleksiyonlar.

Versiyonlama ve yayinlama akisi

• Her entry dokumaninda taslak ve yayinlanmis icerik ayirt edilir: status alani (draft, scheduled, published, archived), taslak lexical ve yayin published objesi.
• Yayinlama sirasinda published.version artirilir ve entryRevisions koleksiyonuna immutable bir snapshot kaydedilir. Bu sayede eski versiyonlara geri donus ve degisiklik karsilastirmasi yapilabilir.
• schedule ozelligi ile gelecekte bir tarihte yayinlamak mumkun.
• Geri alma (rollback) isleminde istenen versiyon entryRevisions'tan alinarak taslak alanina kopyalanir ve istenirse tekrar yayinlanir.

Audit ve zaman damgalari

• Tum koleksiyonlar createdAt, updatedAt, createdBy, updatedBy alanlarina sahiptir. Opsiyonel deletedAt ile soft delete.
• Bu alanlar sayesinde bir kayit kimin tarafindan ne zaman olusturuldu, kim tarafindan guncellendi ve silindi net olarak takip edilebilir.
• Audit log ihtiyaclari icin ayrica bir auditLog koleksiyonu dusunulebilir.

Avantajlar

• MongoDB’nin belge yapisi esnek alanlar (meta) ile performans ve kolay indeksleme saglar.
• tenantId uzerinden partition/sharding ile her kiracinin verisi birbirinden ayrilir ve olceklenebilir.
• WordPress’in postmeta ve terms tablolarindaki daginiklik yerine anlamli koleksiyonlar ve iliskiler; iliskiler ID listeleri ile tutulur.
• Taslak vs yayin ayrimi sayesinde icerik uretim sureci guvenli, surumlu ve geri alinabilir.
• Zaman damgalari ve createdBy/updatedBy alanlari ile icerik sahipligi ve sorumluluk takibi yapilir.

Bu tasarim uzerinde gorus ve onerilerinizi duymak isteriz. Icerigin daha da iyilestirilmesi icin yorumlarinizi paylasabilirsiniz! 😊