e-commerce projemde mongodb kullanmayı planlıyorum, asıl mevzu buradan patlak veriyor yani.
kendime "neden mongodb kullanmalıyım" diye sorup, cevaplar arıyorum ki diğer sql alışkanlığımdan vazgeçebileyim. tabloları doğru kurabileyim.
mongodb üç boyutlu veri saklayabiliyor, evet.
peki soruma gelecek olursak:
diyelim ki products diye bir tablom var. bu tablo sql'de 6-7 tane tabloyla çaprazlanıyordu. nelerdi bunlar?
stok hareketleri, fiyat hareketleri, kategoriler, etiketler vs.
şimdi bu durumda mongodb'de her bir ürünün, stok hareketini, yine bunun içinde bir array olarak saklamak doğru olacak mı? ve bu bana bir avantaj getirecek mi?
Örnek:
{
name: 'güzel ürün'
inventory: [
{
change: -1,
type: 'sales',
date: '2020-09-15 08:00:00'
},
{
change: +5,
type: 'stock in',
date: '2020-09-15 08:00:00',
user (stok girişini yapanı öğrenmek için): {
id: '3',
name: 'Bilal'
}
}
]
}
bu 10-15bin üründen sonra, mongonun 16mb'Lık parçalarını aşmaya başlamasına sebep olur mu böyle bir ağaçlandırma?
aynı tablo altına category'leri ve etiketleri de girmeye başlarsam mesela?
veya fiyat hareketlerini?
örneğin ürünün fiyatı her tarihte değişiyor. ve ben her zaman son eklenen fiyatı satış fiyatı olarak kullanacağım.
yine aynı şekilde ürün fotoğrafları mevcut.
şimdi mysql'de bunları, dediğim gibi 6-7 tabloda birleştirip, relationlar ile gösteriyordum.
mongodb'ye geçersem sanırım yapıyı yukarıda anlattığım gibi değiştirmem gerekecek.
böyle bir geçiş mantıklı mı? hız kazandırır mı? yoksa şişme vs. mi yapar? bu kadar ağaçlandırmak doğru mu?
ya bu arada bu başlık altında biraz daha sorular sorabilirim, soru-cevap şeklinde.
kafamda gerçekten mongodb'ye geçmek benim açımdan mantıklı diyebileceğim noktaya gelemk istiyorum. (aslında şuan o noktadayım zaten. sadece bazı durumlarda başıma iş açar mı onu öğrenmek için sorular soruyorum)
normalde iliskisel veri tabanlarinda mysqlde tablo yapisini belirlerken, yani normalizasyon/denormalizasyon yaparken cogunlukla neye bakiyorsun, tekrar eden verirleri farkli tabloya alayim ve aralarina iliski koyayim ki az yer kaplasin.
mongodb gibi collection yapilarinda ise bakis acisi ise tamamen verinin cagirilmasi ile ilgili. yani bir anlamda domain driven design ile ilgili. bakis acin su olmli, web arayuzunde bir veri seti cagirilacak ise tek seferde cagirilan bu bilgi ayni collection icinde bulunmasi daha iyidir. ornegin urun listesi ve urunlerin stok hareketleri hep farkli ekranlarda farkli cagrilarda yapiyorsan o zaman ayri collection da tutman veri buyuklugu acisindan mantikli olabilir. ama sen ekranda urun listesini getiriken her zaman stok harketini de ihtiyacin var ise o zaman tek collection mantikli olabilir. ama bu tamamen veri setinin buyuklugu ve performansda olcumleme yapmana bagli.
NOSQL dbler, SQL'lere alternatif değil, tamamen farklı bir problemi çözmeyi amaçlayan dbler. Dolayısıyla sizin durumunuzda (veritabanı bir şemaya sahip) SQL daha uygun.
MongoDB'nin sitesinde use case'lere ilişkin güzel örnekler var: (git: www.mongodb.com)
e-commerce alanında biraz aramalar yapınca, genel olarak mongodb yerine sql'in tercih edildiğini gördüm bu arada. hem de ezici bir çoğunlukla. kafamda soru işareti yarattı tabi bu durum, galiba mongo için başka bir projeyi kollayacağım...
ben tercih tercih yaparken eger veri seti buyuk, cesitli, karmasik ise iliskisel veri tabanlarini tercih ediyorum. nispeten kucuk, belirsiz, iliskiler net degil ise nosql veri tabanlarini tercih ediyorum. tabi bu bakis acisinin ilerde yasatabilecegi problemleri iyi analiz ettim diyemem.