resimleri veritabanında saklamak doğru bir yöntemmidir?
Bu yöntemi mysql ile yaptım ancak sitenin hacmi kücük olduğu için(150-3000 ziyaretci; 15-45 kullanıcı) bir problem çıkmıyor.
MsSQL ile beklentileri yüksek olan projelerde bu yöntem ne kadar mantıklı olur?
Resimleri binary olarak sql tarafında tutmak sağlıklı bir yöntem değil. Database in boyutu çok fazla büyür. Resmin path ini tutup resmide klasörlerde saklamak daha uygun olur.
resimleri veri tabanında saklamak yerıne en basıtı ve en güzel şekli bence resmi yüklerken @@IDENTITY ile veri tabanına kayıt edilen son kaydın numarasını alarak resmede o ısmı verıp hosta o sekılde yüklemen ve daha sonrada cagırırken o Id ye gore cağırman daha uygun olur
örneğin'SqlCommand sorguSonid = new SqlCommand("select @@identity", baglanti)'
yada guid kullanarakta yapabilirsin
veri tabanına saklamanı tavsiye ederm sanılanın aksine dosya olarak cekmek ile sql server(ben sql serverde denemiştim) arasında performans farkı olmuyor "trace=true" yaparak aradaki farkı da test edebilirsiniz. veri tabanı dediğim mahlukat bir kolonda 4 gb resim saklayabilecek kapasitede ve yanılmıyorsam karayollarının tüm harikaları 2 ser gb parçalar halinde veritabanında saklı 2 gb de bile (bu sistemi yapan üstadın testine göre) de fark olmadığını söylemişti. kaldı ki veritabanında saklamanı öneririm cünki en basiti veri bütünlüğü ve koruması daha iyi sql server veya mysql serverdeki verileri kurtarmak dosya bazında kurtarma yapmaktan daha kolay diyelim siteyi taşıyacaksın.
alırsın veritabanın götürür ilgili siteye import edersin scripti ftp ile upload edersin bitti. ancak öbür türlü resimleri taşıman gerekir tasıma esnası bozulsa birsey olsa silinse hacker gelse ucursa sıkıntı. ayrıca diyelim resmi sileceksin gidip o resmi file.Exists() ile bulcak var mı bakcan silcen uploadlar esnasında isimler cakisabilir onu kontrol etcen yahut isimlendirip save edeceksin ıvır zıvır.
Veri tabanları terabaytlarca veri yükünün üzerinden rahatlıkla gelebilirler ona uygun hızda ve algoritmada yapılıyorlar.
misal resmi aspx olarak değilde ashx (generic handler di galiba) ile getiri listelersen daha hızlı oluyor ashx in yaşam döngüsü daha kısa microsoftun sitesinde görmüştüm arastırınca öğrenmiştim. vs vs
2.bir ek msdn deki yazılara göre @@IDENTITY yerine SCOPE_IDENTITY() kullanımını tavsiye ediyorlar
Merhaba Arkadaslar,
Guzel bir tartisma olmus, bende bu tartismaya kendi yorumumu eklemek istyorum. Aslinda resmi nerede saklayacaginiz, duruma gore degisir. :) Diyelimki sitemiz cok fazla transaction aliyorsa, DB'nin cok fazla sismesini istemeyebiliriz. Tabi bu arada database'in table space'lerinin isletim sisteminin kuruldugu fiziksel harddiskten farkli bir harddisk uzerine kurulmasi sarttir. Ayrica bu uygulama icerisinde resimlerin farkli boyutlarina ihtiyacimiz varsa bunlarin sisteme yuklenmesi sirasinda bir kod vasitasi ile farkli farkli boyutlara cevirip file sistem uzerinde farkli farkli folderler icerisinde saklamakta faydali olabilir. Web server uzerine gelen requestlerde resimleri file system uzerinden cekmek her seferinde sql server uzerinden cekmekten daha hizli olacaktir. Bunun haricinde internet explorer 7'e kadar bir browser ayni anda bir domain adresinden 2 dosyayi download edebiliyordu. Bu yuzden biz bir download manager kullanmadan internet explorer uzerinden dosya download etmeye calistigimizda ayni anda 2 taneden fazla download edemiyoruz. Fakat browserlari kandirmak icin ayni web server'a yonlendirilmis(CNAME) 1 den fazla domain isimi olsuturulur ise ve sayfadaki resimlerinde adresleri bu farkli domainler uzerinde cagrilirlsa browser bunlari farkli domain gibi gorur ve ayni anda download eder. Buda bizim hizimizi artirir. Ornek vermeye calisayim;
Domain adlarimiz CNAME
-------------------- -------------------
Domain1.MyServer.com http://www.myserver.com
Domain2.MyServer.com http://www.myserver.com
Domain3.MyServer.com http://www.myserver.com
Sayfamizdaki resilmeride bu adreslerden cagirirsak;
Domain1.MyServer.com/images/resim1.png
Domain2.MyServer.com/images/resim2.png
Domain3.MyServer.com/images/resim3.png
Browser bunlari farkli domainlermis gibi gorecektir ve ayni anda indirecektir. Aslinda bu resimlerin hepsi ayni web sever uzerindedir. Resimleri File System uzerinde tutmanin boyle avantajlari disinda tabiki dezavantajlarida vardir. Bunlardan biri eger uygulamamiz bir web farm uzerinde calisiyor ise resimlerin her web server uzerinde birer kopyasinin bulunmasi gerekir. Diyelimki A kullanicisi 1. web servera kendi profil resmini yuklerse bu resim 2. ve 3. web serverada kopyalanmalidir. Burada cozum web serverlar uzerinde bir DFS kurmaktir. DFS(Distributed File System) 1 web servera kopyalanan imaji diger web serverlarada otomatik olarak kopyalar. DFS microsoft ile gelen bir cozumdir. Bunun disinda daha ozellestirilebilir yazilimlarda mevcuttur. Mesela Wansynch bunlardan biridir. Wansynch sadece degisen bitleri update eder. Diyelim bir word dokumani her 2 serverdada var. Dokumana yeni bir sayfa eklediniz sadece bu sayfayi diger serverlara gonderir. Iste resimleri file system uzerinde tutmanin zor tarafalarindan biri bu islemerin yonetilmesidir. Ayrica backup islemlerindede yine Mahoni nin dedigi gibi SQL server gibi tek bir merkezi yerden backup alamayiz. Ayri ayri her folderin backup'inin alinmasi gerekir. Eger sql server 2000 kullaniyor olsaydiniz resimleri kesinlikle file sistem uzerinde tutun derdim fakat sql 2005 ve 2008 de bu performans sorununu cozduklerini iddia ediyor microsoft muhendisleri. SQL server uzerinde tutarsaniz backup islemleriniz cok kolay olur. Ayrica SQL serverin yeni ozelliklerinden biri olan harita imajlari uzerinde arama ve sorgulama yapabilme ozelligi oldugunu unutmamak gerekiyor. Ileride imajlar uzerindeki yazilari okuyup sorgulama yapma imkanimizda olabilir diye dusunuyorum. Bu durumda SQL Server bize yeni avantajlar katabilir.
Saygilarimla,
Fatih.
Mesaj göndermek için giriş yapmalısınız.