Tüm Platformlar için Hızlı Uygulama Geliştirme Kitabı... Delphi
Ön Sipariş Talebinde Bulunan Üyelerimiz
Sipariş Talebinde Bulunan Üyelerimiz

Konuyu Paylaş : facebook gplus twitter

Konuyu Oyla:
  • Derecelendirme: 0/5 - 0 oy
  • 1
  • 2
  • 3
  • 4
  • 5
Veritabanında resim saklanmalı mı, saklanmamalı mı ?
#1
Merhaba, 
Firebird veritabanı kullanarak oluşturduğum çok kullanıcılı projede, dbgridde seçili kaydın resmini image da gösteriyorum. ( oda ayrı bir sorun  )
Bu resimleri bir dizinde mi , yoksa veritabanında mı tutmak daha doğru karar veremedim. Forumda ilgili konulara baktığımda kimi dizinde tut derken kimide hayır veritabanında tut, düzgün ayarlar ve kaydedersen gayet hızlı ve sorunsuz çalışır demiş.  İşin sonunda keşkee dememek adına iki sorum olacak, deneyimlerinizi ve fikirlerinizi paylaşırsanız sevinirim.

1) Resimleri veritabanında saklarsak ( veritabanında saklanabilen ideal resim boyutu nedir. )
2) Resimleri dizinde saklar ve kullanıcıların o dizine kaydetmesini ve okumasını sağlarsak , İlgili ürüne yeni resim eklerken, kişinin ana bilgisayar üzerinde dosya okuma ve yazma yetki problemi başımıza bela olurmu ?

Resimleri nerede tutmalıyım , Veritabanı - Dizin mi?

Teşekkürler
Cevapla
#2
dizin en mantıklısı ben dizinde tutuyorum okuma yazma problem olmaz.. Ama tabii proje açıklaması yapmamışsın maksimum kaç kaydın ve kaç fotoğrafın olabilir projede
Cevapla
#3
tuttuğun resim avatar gibi 100-200kb'lik bir şeyse küçük bir tablo ise pek sorun olmaz küçük datalarda ancak büyük fotoğraflar tutacaksan ve çok fazla kayıt olacaksa veritabanını boş yere büyütmemeni öneririm , büyük firmaların hiç biri databasede fotoğraf tutmuyor.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Kuvvete dayanamayan adalet aciz, 
Adalete dayanamayan kuvvet zalimdir.
WWW
Cevapla
#4
Cevabı genelde değişebilen bir soru sormuşsunuz. Ancak benim açımdan cevap pek değişiklik arz etmiyor. Benim cevabım veritabanında tutulmalı.

Resimler herhangi bir dizinde tutulur ise;

1- Dizinin adının değişme ihtimali, bir veritabanı içindeki tablonun adının değişme ihtimalinden kat be kat büyüktür. Dolayısı ile resimlerinize erişememe ihtimaliniz vardır.
2- Dizin içinde saklı olan resim dosyalarını değişmeye ve silmeye karşı koruyamazsınız. Uygulamanız haricinde, ilgili dosyalara erişim sağlanabilir, değiştirilebilir, silinebilir.
3- Sorun saklanacak resimlerin büyüklüğü ise; bunun dosya sistemi üzerinde durması ile veritabanı üzerinde durması arasında büyük fark olmayacaktır. "Büyük resim, büyük sorun" her iki durumda da devam edecektir.


Resimler veritabanı içinde bir tabloda tutulur ise;

1- Tablonun adının değişme ihtimali yoktur (ya da yok denecek kadar azdır), dolayısı ile resimlerinize ulaşamama gibi bir sürpriz ile karşılaşmazsınız.
2- Resim verilerinizi tablo içinde silme ve değişikliğe karşı trigger'lar ile koruyabilirsiniz. Zaten yetkisiz kullanıcılar tablonun içindeki verilerinize erişemezler. Oysa bir klasöre herkes erişebilir.

Dikkat edilmesi gerekenler;

1- Resim verilerinin bire bir boyutlarda olması önemli değil ise, belirli bir ölçüye ölçeklendirerek veritabanı üzerinde saklamanız faydalı olacaktır.
2- İlgili verileri bir tablo içinde saklayacak iseniz, mümkün ise bu tablo sadece resim verisini içerecek alan ve ilişkili alanı içermeli.

Örneğin: UserImages tablosu
  Id        : Integer // AutoInc, PK
  UserID : Integer // FK
  Photo  : Image

Bu sayede gerçekten resim verisine ihtiyacınız olduğu durumlarda bu tabloya erişimde bulunursunuz(Join vb). Durum bu ahvalde iken ilgili tablodan "SELECT * FROM" ile veri çekmemelisiniz.
3- Bu tarz bir tablo üzerinden seçim yapar iken, "SELECT * FROM" ile veri çekmeyin ! , resim verisine ihtiyacınız yok ise o veriyi boş yere taşımayın. (2. defa yazdım çünkü gözden kaçıyor)

Bu ve buna benzer nedenlerden ötürü, ben resim verilerini veritabanı üzerinde tutmayı seviyorum. Bu sayede kontrol tamamen bende oluyor ve sürprizlerle karşılaşmıyorum. Benzer nedenlerden ötürü, uygulama ayarlarını da plain text halinde dosya sisteminde tutmaktan hoşlanmıyorum. Kontrolüm ve bilgim dahilinde değiştirilebilir/silinebilir çünkü.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla
#5
Merhaba,
Dizinde tutulması konusu, şahsi görüşüm, bana mantıklı gelmiyor. verinin mahremiyeti açısından özellikle. Resimlerinizi ayrı bir tabloda tutun, detay bilgilerini ayrı bir tabloda. İndex yapınızı oluşturduğunuzda Master-Detail yapısı ile çok hızlı işlem yaparsınız. Master tabloda ID,kimlikno,Ad,Soyad,DYeri gibi bilgileriniz olsun Detay tabloda ise ID,MasterID,Resim alanlarınız olacak şekilde oluşturduğunuzda yavaşlık söz konusu olmayacaktır böylece dataları herkese açık bir alanda tutmamış olursunuz.
Dosya boyutu konusunda sıkıntı yaşayacağınızı düşünmüyorum.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol

İyi Çalışmalar.
Cevapla
#6
Kısaca Hayır. Kapladığı yer hesaba koyulursa resimleri veritabanında tutmak hata yapmaktır. Image, Blob gibi alanlara gizlenen resimlerin gizlenme sebebi "gizlilik"tir.

Eğer ürünlerin resimleriyle ilişkisini yönetip, ekranda ürünler çağırılırken hangi resim kime ait bilmek istiyorsanız;
1- Prodüksiyondaki ürünün ana dizininde Data isminde bir klasör oluşturun. Dünya çapında genelde bu isimle belirtilir.
2- İçerisinde Images yada sizin kullanacağınız isimle bir klasör daha oluşturun.
3- Modül bazlı ayırım yapacaksanız modül ismini yazın, değilse buraya oluşturabilirsiniz.
4- Veritabanınızda string değer tutabileceğiniz herhangi bir alanda [AppDirectory]/Data/Images/0001.png olarak muhafaza edin.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Cevapla
#7
Şimdi okuyunca baktım, geçen yılki evrak veritabanım 1 gb 13k dan biraz fazla kayıt var, bu yılki şimdiden 1 gb olmuş daha da tarayacağım binlerce evrak var diyebilirim, dolayısı ile 2 gb olacak gibi, ondan önceki yılları dizinde tutuyordum yedeklemesi tam bir eziyet, dosya tek olunca yedekleme de kolay oluyor, onu aldımı bunu aldımı diye düşünmüyorum. Kısaca Veritabanında düzgün bir şekilde tutarsanız hiçbir sorunla karşılaşmazsınız. Gerektiğinde tek tek kayıt çekip ekrana basın gerisini düşünmeyin.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
WWW
Cevapla
#8
Ayrıca kayıt sayısı çok yüklü olacaksa alanları mümkün olduğunda azaltmakta fayda var. Mesela personel bilgilerini tutarken ad, soyad, tc no gibi kritik alanlar ana tabloda tutulmalıyken adres bilgileri başka tabloyla iilişkilendirmekte fayda var. Hem böylece çoklu adres tanımı da yapmak mümkün olabilir. Aynı durum resim içinde geçerlidir. Gerçi her ne kadar vesikalık resimler çok yer kaplamasa da personel resimleri için ilişkili farklı tablo tasarlamakta fayda var. Böylece sadece resimleri bulunan personeller için kayıt oluşturursunuz. Tabi nasıl bir yapınız ve tasarımınız olacak bilemiyorum ama bu personel bilgisi de olsa, evrak bilgisi de olsa resim alanındaki bilgiyi açıklamayan çok sayıda alanı bir arada tutan bir tablo tanımlanmamasında fayda olacaktır.
Cevapla
#9
Merhaba,
Ben de bir soru ile konuyu biraz genişleteyim. 
Resim dosyasının veri tabanı üzerinde binary (olduğu gibi) olarak mı saklanmalı ya da base64 formatında mı saklanmalı?
Performans veya veriyi işleme açısından (her iki durum için) ne gibi farkları olur?
While true do; Hayat döngüsü, kısır değildir! Yapılan bir yanlış, o döngünün dışına çıkmanızı sağlayacaktır.
WWW
Cevapla
#10
(17-10-2018, Saat: 10:16)Fesih ARSLAN Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlMerhaba,
Ben de bir soru ile konuyu biraz genişleteyim. 
Resim dosyasının veri tabanı üzerinde binary (olduğu gibi) olarak mı saklanmalı ya da base64 formatında mı saklanmalı?
Performans veya veriyi işleme açısından (her iki durum için) ne gibi farkları olur?

Base64 olarak saklamaya kalkarsanız sağ eliniz ile sol kulağınızı tutmaya çalışırsınız gibi geliyor bana. Neticede boyut artacak ve çevrim maliyetleri de ortaya çıkacak. İlla orjinal dosyaya bir şey yapılacak ise bence sıkıştırma işlemi yapılıp kayıt edilmesinde fayda vardır.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla

Konuyu Paylaş : facebook gplus twitter





Konuyu Okuyanlar: 1 Ziyaretçi