Resimleri dosya olarak mı yoksa bir web uygulaması için veritabanında mı depolamak istiyorsunuz?

Sorum oldukça genel ve buna% 100 bir cevap olmayabileceğini biliyorum. Çok sayıda resim ve umarım makul miktarda trafik içeren bir ASP .NET web çözümü oluşturuyorum. Gerçekten performans elde etmek istiyorum.

Resimleri Veritabanına mı yoksa Dosya sistemine mi kaydetmeliyim? Cevap ne olursa olsun neden belirli bir yol seçtiğiyle daha çok ilgileniyorum.

Çok teşekkürler Stefan

DUPLICATE : DB'de Görüntüleri Saklama - Evet mi Hayır mı? , Dosya sisteminizde resimler nasıl saklanır , Az sayıda resim depolanır : blob veya fs? ve muhtemelen diğerleri.

YORUM: Birçok güzel yanıt için teşekkürler. % 100 veritabanı odaklı bir çözüme sahip olma fikrini sevsem bile dosya tabanlı bir çözüme gideceğim. Bugün veritabanları vb. İle istediğimi yapmak için iyi çözümler var gibi görünüyor ama yapmamak için birkaç nedenim var.

• Barındırılan bir çözümde olacağım, çok büyük miktarda depolama alanım (10gb) var, ancak veritabanı için yalnızca 300mb. DB'de ekstra depolama için çok maliyetli olacaktır.

• Ben bir DB uzmanı değilim ve ayrıca DB ayarlarının kontrolünde değilim. DB tabanlı bir çözüm, göründüğü gibi özel konfigürasyona ihtiyaç duyabilir.

Siteyi kendi sunucumuzda çalıştırmak için taşınacaksak, DB tabanlı bir çözüm düşünebilirim. teşekkürler Stefan

Resimleri dosya sisteminde ve resim konumlarını veritabanında saklayın.

Neden? Çünkü...

1. Resimleri statik dosyalar olarak sunabileceksiniz.
2. Resimleri almak için herhangi bir veritabanı erişimi veya uygulama kodu gerekmeyecektir.
3. Performansı artırmak için görüntüler farklı bir sunucudan sunulabilir.
4. Veritabanı darboğazını azaltacaktır.
5. Veritabanı nihayetinde verilerini dosya sisteminde depolar.
6. Dosya sisteminde saklandığında resimler kolaylıkla önbelleğe alınabilir.

Yeni geliştirdiğim projelerimde, görüntüleri (ve her türlü ikili belgeyi) veritabanı tablolarında görüntü sütunları olarak sakladım.

Veritabanında depolanan dosyalara sahip olmanın avantajı, veritabanı (= meta veri) ve sabit disk (= dosya depolama) arasındaki senkronizasyon yerleşik olmadığından, bir kayıt silindiğinde sabit diskte referans verilmeyen dosyalar ile sonuçlanmayacağınızdır. ve manuel olarak programlanmalıdır.

Bugünün teknolojisini kullanarak, görüntüleri SQL Server 2008 FILESTREAM sütunlarında depolamanızı öneririm (en azından bir sonraki projemde yapacağım şey budur), çünkü bunlar veri tabanında veri depolama VE ayrı dosyalarda büyük ikili dosyalara sahip olma avantajını birleştirirler ( en az reklama göre;))

Atasözü her zaman "Dosya sistemindeki dosyalar, veritabanındaki dosya meta verileri" olmuştur.

Dosyaları dosya olarak depolamak daha iyidir. Farklı veritabanları Blob verilerini farklı şekilde işler, bu nedenle arka ucunuzu taşımanız gerekirse başınız belaya girebilir.

Sunucuda zaten var olan bir dosyaya bir <img src = görüntü sunarken, veritabanı alanından geçici bir dosya oluşturup <img etiketini buna işaret etmekten daha hızlı olması muhtemeldir.

Bu yanıtı, sorunuzu gözden geçirerek ve http://databases.aspfaq.com/database/should-i-store-images-in-the-database-or-the-filesystem.html adresindeki yorumları okurken buldum.

genellikle veritabanında ikili dosyalar bulundurmayı severim çünkü:

• veri bütünlüğü: başvurulmayan dosya yok, ilişkilendirilmiş herhangi bir dosya olmadan veritabanında yol yok
• veri tutarlılığı: bir veritabanı dökümü alın ve hepsi bu. hayır "O, bu veri dizinini targz etmeyi unuttum."

Görüntüleri veritabanında depolamak, tek görüntülere hizmet etmek için bir DB ek yükü ekler ve bu seviyeye büyürseniz alternatif depolamaya (S3, Akami) aktarmayı zorlaştırır. Bunları veritabanında saklamak, uygulamanızı farklı bir sunucuya taşımayı çok daha kolay hale getirir çünkü şu anda taşınması gereken yalnızca DB'dir.

Görüntüleri diskte depolamak, alternatif depolamaya aktarmayı kolaylaştırır, görüntüleri statik öğeler haline getirir, böylece görüntüleri önbelleğe alınabilir hale getirmek için web uygulamanızdaki HTTP başlıklarıyla uğraşmanıza gerek kalmaz. Olumsuz yanı, uygulamanızı farklı bir sunucuya taşırsanız, resimleri de taşımayı hatırlamanız gerekir; kolayca unutulabilecek bir şey.

Web tabanlı uygulamalar için, görüntülerinizi depolamak için dosya sistemini kullanmaktan daha iyi performans elde edeceksiniz. Bunu yapmak, uygulamanızda birden çok düzeyde görüntülerin önbelleğe alınmasını kolayca gerçekleştirmenize olanak tanır. Görüntüleri bir veritabanında depolamanın bazı avantajları vardır, ancak çoğu zaman bu avantajlar istemci tabanlı uygulamalarla birlikte gelir.

Şimdiye kadar zaten iyi olan cevaplara biraz daha eklemek için. Her iki web düzeyinde de önbelleğe almanın avantajlarından hâlâ yararlanabilirsiniz.Resimleri veritabanında tutan rotaya giderseniz, veritabanı düzeyinde .

Veritabanı için bunu, görüntüleri kendileriyle ilişkili metinsel verilerle ilişkili olarak nasıl saklayacağınız ve veritabanının sorguyu önbelleğe alabilmesi için belirli bir sorguya görüntülere erişebildiğinizle başarabileceğinizi düşünüyorum (sadece teorik olarak bu kısımda beni bombalamaktan çekinmeyin).

Web tarafı ile, sanırım soru asp.net ile etiketlendiğinden, görüntüleri sunmak için bir http işleyicisi kullanma yoluna gideceğinizi tahmin ediyorum. O zaman, çerçevenin tüm avantajlarına sahip olursunuz ve yalnızca görüntünüzün anahtarını http işleyicisine iletmek zorunda kalmadan etki alanı mantığını daha temiz tutabilirsiniz.

Dosyalarınızı depolamak için neden bireysel bir NoSql veritabanı seçmiyorsunuz?

@Chburd'un da bahsettiği gibi veri bütünlüğünü, veri tutarlılığını size getiriyor.

Siz rdbms hala küçükken.

1. İşte Eclipsegörüntüleri dosya sisteminde depolamanın ve meta verilerini DB'de tutmanın adım adım bir örneği (genel yaklaşım, Bahar uygulaması ) - http://www.devmanuals.com/tutorials/java/spring/spring3/mvc /Spring3MVCImageUpload.html
2. İşte bir örnek de - http://www.journaldev.com/2573/spring-mvc-file-upload-example-tutorial-single-and-multiple-files
3. Ayrıca bu projenin bir kod tabanını inceleyebilirsiniz - https://github.com/jdmr/fileUpload . Bu denetleyiciye dikkat edin .