Selamlar,
Bu konuda arkadaşlarınsıklıkla düştüğü sorunlardan biri de bu YAVAŞ olayı.
Size ben tecrübelerimden bahsedeyim (Benim uyguladığım Yöntemden Bahsedeyim)
Şu anda bir program geliştiriyorum bu programda deneme yaptım 100,000 Cari Hareket, 40,000 Stok Kart, 100,000 Kasa Hareketi vs. gibi (Test Data ile) denemeler yaptım 1 saniye içinde hiçbirşey gelmemezlik yapmıyor.
Programda Firebird, IB Bileşenleri ile birlikte kullanıldı.
Tavsiyeleri Sıralıyorum,
1.Liste ekranlarınızda mutlaka filtre koymalısınız, Yani SELECT * FROM TBL_CARI_HAREKET gibi bir selecti, Kullanıcı istemedikçe kullanmamalısınız. Mutlaka bir filtreleme yapmalısınız. En kötü ihtimalle, Tarih Filtresi yapıp kayıtları 1 ay gibi yada kayıt yoğunluğunuza bağlı olarak belirli bir gün aralığında getirtmelisiniz ki, kullanıcı beklemesin. Şunu unutmayın, Denizden Suyu, bardakla, kovayla, tankerle çekebilirsiniz ama en hızlısı muhtemelen en küçük olanıdır. Yani siz bilgi havuzunuzdan sadece yeterli miktarda bilgiyi çekmelisiniz. Eğer herpsini çekerseniz boşuna hem network trafiği oluşturursunuz, client için bellek sıkışmasına yol açarsınız, eğer clientınızda yeterli miktarda bellek yoksa windows hemen swappinge dayanır, üstüne üstlük kullanıcıyı dagereksiz bir bekleme sürecine itersiniz. Bu kaynak müsrifliği olur. Bunu mutlaka aklınızda bulundurun. Müsriflik yok !!!!
2. Yine liste ekranlarında bilgileri gridlerinize yeter kadar kolon sayısıyla alın. Yani Hem Query nesnelerinizde SELECT * FROM TABLO gibikullanım yapmayın, hem de Gridlerinizde kullanmayacağınız alanlarınızı grid nesnesinden temizleyin. Ayrıca Query nesnesinde kullanacağınız fieldlarınız belirli ise, SELECT * yerine SELECT CRK_ID, CRK_KOD, CRK_UNVAN gibi sadece ilgilendiğiniz alanları getirin. Bu bellek ve network trafiği müsrifliğinin önüne geçecektir.
3. Programlarınızı yazarken sıklıkla DB'den birşeylerin alınmasına gerek duyulan işlemleri yani herhangi bir işlem yap, sonraki kayda geç, bilmem neyi kontrol et öyleyse git şuna bak olmazsa sonraki kayda git, şunu güncelle bunu yap... gibi bir sürü şeyu içeren işlemlerinizi Stored Procedure'lere yaptırın. Bu işinizi çok ama çok hızlandıracaktır. Yazmış olan kişiler bilir. Cari Kart Ekstresi (Devirli ve Kümülatif Bakiyeli) raporu hazırlamak benim uyguladığım bu yöntem sayesinde, sizlere örnek olması için söylüyorum 350 sayfa kadar rapor 3-4 saniye içinde hazır oluyor. Gerisini varın siz düşünün.
4. Indekslere özen gösterin, sorgularınıza göre indeksler oluşturun. Indeksleme tariflerini daha önceden bir yazıda anlatmıştım, isteyen arkadaş oraya göz atabilirler.
5. Referantial Integrity denen ilişkisel bütünleşikliği kullanın. Foreign Key'ler kullanın. PK'larınızı mümkün mertebe Integer olarak tanımlayın, string kullanmayın. Integer işlem yapmak, string işlem yapmaktan Kat be Kat hızlı ve ayrıca bellek kullanımı açısından da oldukça düşük bir maliyeti olacaktır. Tabi Foreign Key bağlantılarında getirdiği kolaylık ve hız da cabası.
6. Ben IB componentlerini kullanırken, TIBTble yerine TIBQuery nesnesini kullanıyorum ve bununla birlikte, TIBQuery nesnesine TIBUpdateSQL Nesnesini bağlıyorum. Bu programın hızlanmasını sağlıyor. Ayrıca Query nesnesinde Insert, Update ve Delete gibi işlemleri yapabilmenizi sağlıyor.
7. Her ne kadar tercih edilmese de yada terkedilse de Cached Update olarak ben yazılımlarımı geliştiriyorum. Bu network trafiğinin düşürülmesinde ve ayrıca ben belirtmeden, yaptığım herhangi bir değişikliğin ApplyUpdates demediğim müddetçe Client tarafında kalmasını sağlıyor. Böylelikle, örneğin Fatura kaydına girdiniz, fatura detaylarından birkaçtanesini sildiniz, birkaç tane eklediniz, bazılarını da düzelttiniz ama sonra vazgeçtiniz. Eğer Live bir şekilde fatura bilgilerini DB'ye yansıtıyorsanız, geçmiş olsun. Ama CachedUpdates kullanıyorsanız, problem yok ! CancelUpdates dersiniz, yaptığınız bu değişikliklerin hiçbiri DB'ye yansıtılmaz. Olay client tarafında kalır ve iptal edilir. Bir nevi RollbackTransaction gibi. Ama CachedUpdates'i kullanmak isteyen arkadaşların da bu tür olayları bilip, ona göre dikkatli kullanması gerekiyor. Dikkatsiz kullanımlardan kaynaklanan hatalarda ne yazık ki haksız yere CachedUpdates şamar oğlanı, günah keçisi ilan ediliyor.
Ama doğru kullanıldığında da tadından yenmez bir özellik.
8. View'ler oluşturun, Triggerlar yazın. Client tarafında yapılacakları mümkün mertebe server'a yığın. Manuel yapılması gereken kontrolleri veya kayıt işlemlerini bu tür (veri tabanına ait) yardımcılarla yaparsanız hızınız çok artar. Şunu unutmayın, server size hizmet için orada, bu sebeple clientı meşgul etmeyin. Ayrıca, yanlış bir şey mi oldu, RollbackTransaction deyin olsun bitsin, hiçbir şey olmamış durumuna geri dönersiniz. Böyle bir kolaylık varken neden kullanmayasınız ki? Neden herşeyi illa EXE programın yapmasını istiyorsunuz. İşinizi planlayın ve mümkün olan her şekilde program içindeki işlemlerinizi triggerlara ve splere taşıyın. Ama dikkat edin herşeyi taşıyacağım diye de, kalkıp INSER işlemi için SP yazmak, DELETE işemi için SP yazmak gibi külfetlere de girmeyin. Mümkün olduğunca orta noktayı (denge noktasını yakalayıp) taşıyabildiğinizi taşıyın. Düşünsenize, bu şekilde çalışan bir iş yerinde Server'ın kapasitesini artırmak mı kolay olur yoksa Client'ların kapasitesini arttırmak mı? Server iş yükünüzü çeksin. Özellikle Firebird gibi güçlü veritabanları bu işler için tasarlanıyor ve geliştiriliyor. Siz boşuna kasmayın
9. Program açılışlarında düşülen hatalardan biri de langır lungur her tabloyu (lazım olmadığı halde) açmaktır. Lazım olan tabloyu, lazım olduğu yerde, lazım olan fieldları, lazım olan bilgi kadar açın, kullanın ve kapatın. Aksi halde, hem network trafiğini arttırırsınız hem de belleğinizi şişirirsiniz. Lazım olanı, lazım olduğu yerde lazım olduğu kadar.
10. Aynı şekilde, formlarınızı da kullanılacağı zaman create edin ve işi bitince de Free edin. Bellek sıkıntısı yaşamazsınız. Özellikle düşük konfigürasyonlu makinalarda, bellek sıkıntısı yaşayan arkadaşlara tavsiyedir. Eğer buna dikkat etmezseniz, Windows acımasız bir biçimde swappinge girişecektir ve bir formun açılması dakikalarca sürecektir. 9. ve 10. madde birbiriyle bütünleşik olarak düşünülüp tasarlanmalıdır.
Valla arkadaşlar şimdilik aklıma gelen bunlar. Bunları uygularsanız emin olun, programlarınız şakır şakır çalışır. Beklemek kelimesi de size bir anlam ifade etmez (Tecrübe ile sabittir). Bekleme ancak ve ancak, kullanıcı istediği zaman yapılmalıdır. Yani gerçekten çok uzun bir şlem yapacaksa kullanıcı beklemelidir. Yani binlerce sayfa bir rapor alacaksa yada kayıtların tamamını gride alıp üzerlerinde gezinecekse o zaman kullanıcı bilinçli bir şekilde beklemeyi göze almalıdır. Aksi halde yazacağınız programlar Lütfen Bekleyinizden geçilmez.
Bunlar benim şahsi tecrübelerim olmakla birlikte, her yiğidinbir yoğurt yiyişi vardır diyerek sözlerimi sonlandırıyorum.
Kolay Gelsin.
