Firebirdde editler ve next yavaş sqller hızlı ne yapmalıyız?

[yuksel2004]

Arkadaşlar biraz sıktığımın farkındayım ama bu firebirdü öğrenmem lazım.Şimdi IBDatasetle firebirde bağlanıyorum.Ve 20 alanlık bunun yarısı BLOB olan bir tablee sahip bir dbyi deniyorum.İnsert hızı mükemmel.For döngüsü ile 1000 kaydı 2 saniyede yazıyor.Ama 15.000 kayıtta dataset.edit yada dataset.last dediğimde program tıkanıyor.Klasik yanıt vermiyor uyarısı.Ram kullanımı zirvede falan.Windows sanal bellek artır diyo.Pc 2.8 işlemci ve 512 ram sanal bellekle birlikte 1,5 gb falan
Select sorgularıda çok hızlı.Sorun burada yeni bir kayıt gireceğim zaman programın çok beklemesi 1 dakika filan ve sonrada yanıt vermemesi.Sizce sorun ne olabilir.Bir yerde hata yapıyorum ama nerede.İndexte kullanıyorum..Yoksa şöylemi yapmalıyım.Edit ve post olaylarını bırakıp herşeyi update ve insertlemi yapsam acaba?Ama o zamanda first ve last komutlarını ne yapıcaz?Cevaplarınız için teşekkürler.Hepinize kolay gelsin.

[rsimsek]

ibx bileşenlerin ve delphi in update li mi?

[yuksel2004]

Evet Delphi7 ve firebird 1.5 Ne yapacağımı şaşırdım.Accessi bırakıp Firebirde geçmek istiyorum ama daha 10-15 bin kayıtta çuvallıyorum.Mutlaka bu firebirdle alakalı değil ama benim yapamadığım bir şeyler var muhtemelen.Yoksa bu kadar büyük projelerde kullanılan bir db böyle olamaz.Hata bende ama bulamıyorum.IBsql nesnesi ile denedim sonuç aynı.Şu enteresan ki insert ile 1000 kayıdı for döngüsü ile 1 saniyede giriyorum ama tahminen 15-20 bin olduğunu bildiğim tabledeki kesin kayıt sayısını bile öğrenemiyorum.Çünkü son kayıda gidemediğimden.Son kayıt deyince tıkanıyo.Oysa MSAccess'de 500.000 kayıtta son kayıt dediğimde 2 saniye bile sürmeden son kayıta gider 2 saniyede post işlemini yapardı.Ancak oda sql sorguların bu yüksek kayıtklarda çalıştırmıyor.Var olduğunu bildiğim kayıtları yok diye çıkıyor işin içinden.Tekrar ilginize teşekkürler.

[rsimsek]

Sıfırdan tek form bir proje oluşturup sadece tabloya bağlanıp son kayıta gitmeyi dene muhtemelen program içinde ekstradan bir şeyler yapıyor olabilirsin..

[yuksel2004]

Abi ilgine çok teşekkürler.Ama zaten bu bahsettiğim tek bir form ve yeni
bir proje.Yani ben bu projeyi firebirdü öğrenmek için yaptım.Eğer başarılı olursam Asıl projemdeki dbnin aynı alan dları ve tablelar ile firebirdde oluşturup dataset ieimlerini aynı isimden vererek IBdatasetlere çevirip eğer çıkarsa hataları temizleyip firebirde çeviricemde.Bu deneme yani.Zaten arkadaşlar söylüyorlardı sql sorgularında hızlı diğerlerinde yavaş diye ama bende yavaş olsa razıyım program tıkanıyo.Tekrar teşekkürler.

[vedatkaba]

deniyorum.İnsert hızı mükemmel.For döngüsü ile 1000 kaydı 2 saniyede yazıyor.Ama 15.000 kayıtta dataset.edit yada dataset.last dediğimde program tıkanıyor.Klasik yanıt vermiyor uyarısı.Ram kullanımı zirvede falan.Windows sanal bellek artır diyo.Pc 2.8 işlemci ve 512 ram sanal bellekle birlikte 1,5 gb falan
Select sorgularıda çok hızlı.Sorun burada yeni bir kayıt gireceğim zaman programın çok beklemesi 1 dakika filan ve sonrada yanıt vermemesi.Sizce sorun ne olabilir.Bir yerde hata yapıyorum ama nerede.İndexte kullanıyorum..

Merhaba Nasıl yapıyorsun bilmiyorum ama ,,

Ben firebird ü test ettiğimde mükemmel sonuç..Celeron 2.4 ve 256 Ram le 25.000 Kayıt'ı 1 dakika 19 saniye de kayıt ediyorum.ve ne tıkanma ne bir sekme ne öksürme hiç birişey yok.kolay gelsin.

[Kuri_YJ]

Selamlar,

Bakın bir noktaya açıklık getirelim, sizin yaşadığınız hız sıkıntısı muhtemelen 25-30 bin veya daha yukarı boyutlardaki bir table'ı open ederek tüm kayıtların belleğe yüklenmesi ve bu bilgiler içindeki BLOB alanların fazlalığı ile ilgilidir.

Şimdi eğer bir Select cümlesi kullanıyorsanız Network trafiğini azaltmak maksadıyla BLOB alanları mümkün olduğunca az kullanarak ve sadece ihtiyaç duyulduğunda yüklenecek şekilde tasarımınızı yapmanız gerekmekte. Bu sadece FB için geçerli olan bir mantık değil tüm RDBMS'lerde yaşabilecek bir sorun. Yani optimize kullanamamaktan kaynaklanıyor.

Örneğin, 80 alanı olan ve bunlardan 75'inin BLOB olduğu bir table'da 1000-2000 Kayıt olduğunu varsayın ve table'ı open edin. Sonrada Locate gibi işlemler yaptırın,

Sonucun çok da farklı olmadığını göreceksiniz. Bu sebeple bu tür yapıları kurarken, işinizi tek bir SQL cümlesi ile halledebilecek ve gereksiz kayıtların belleğe yüklenmesini önleyecek mantıklar geliştirmelisiniz.

Örneğin listeleme (bir grid içerisinde başlık kayıtlarını göstermek gibi ) bir şeyler yapıyorsanız, bunu en az alanla halletmeye ve sınırlı sayıda kayıt getirmeye çalışarak yapmalısınız. Örneğin bir tarih kriteri vererek belirli tarih aralığına düşen belirli kayıtları göstermek gibi.

Cari bir programda tüm hareketleri getirmeye kalkarsanız hem FB server'ı hem de networku gereksiz kayıtlarla boğarsınız. FB Server boğulmaz ama Server (Hardware olarak boşuna,gereksiz kayıtlarla meşgul olur) bu sebeple bu tür durumlarda Tarih, fiş tipi gibi kriterleri koyarsınız ve Query sonucundan dönen datasetinizde 100-150 arası kayıt kalır ve kimse üzülmez. Eğer kullanıcı tm kayıtları görmek isterse, kriterlerle oynayabileceği bir panel açarsınız orda kriterleri istediği gibi değiştirebilir.

Bu yöntemi kullanın. Data yoğunluğunu azaltın (server'da isterseniz 1 milyar kayıt olsun hiç önemli değil) siz Client'a bilgiyi hep minimum düzeyde getirin.

Bu şuna benzer, ha denizden 1 kova su getirmek, ha havuzdan 1 kova su getirmek gibi. Yani Data'nın merkezinde bilginin çokluğu değil sizin kovanız a veya taşıdığınız araca yüklediğiniz bilgi yoğunluğu ve çokluğu önemli.

Eğer 1 bardak su ihtiyacı olan yere sürekli tankerle su taşırsanız, sizi kovarlar 1 bardak su ihtiyacı varsa oraya 1 bardak su götürün. Kovayla ihtiyaç varsa kovayla, tankerle ihtiyaç varsa tankerle

Bilmem anlatabildim mi!...

Sevgiler

[oguzozturk74]

Çok iyi anlattın abi , ağzına sağlık