Firebird de hjızlı bir yapı için..!

[feinpus]

Selamlar,

6 adet tabloda bulunan veriyi tek tabloda toplayarak bir formumda listeliyorum. Fakat bu işlemi paradoz veritabanında ayrı bir tablo oluşturarak yapıyordum.

Yani bir tablo yaptım stok diye ve bu ilgili 6 tabloda değişiklik olduğunda bu tabloya da ayrıca kayıt ekliyor. Bende gerekli bilgiyi bu tablodan alıyordum. Bu arada bu tabloya her dakika hatta her saniye veri girişi oluyor. Epeyde kayıt var.

Şimdi FireBird e geçtim veritabanımdaki bu mantığı koruyayım mı yoksa daha kolay ve yöntemler var mı?

Örneğin ilk olarak view tablosunu duydum ama forumda okuduklarımdan sonra sürekli kayıt değişikliği olan bir veri tablosunda ne kadar hız sağlar emin olamadım.

Sizce view tablosu benim kullandığım gibi olabilir mi?

Yoksa aynı yapıyı firebird'de de kurayım mı?

[macsonfor]

Bahsettiğin veritabanını hangi projede kullanacaksın kullanım amacı nedir açıklarsanız sanırım daha iyi olacaktır...

[sadettinpolat]

çok gerekmedikçe diğer tablodaki bilgileri başka bir tabloya kaydetmek pek doğru değil gibi. çünkü dbyi gereksiz yere şişirir. view veya sp içerisinde join kullanılarak çözülebilecek bir yapıysa view veya sp kullanın. veya duruma göre (veriler kalıcı olmayacak ise) memory tablolar kullanılabilir. kayıtları başka bir tabloya kaydetmek en son seçeneğiniz olsun bence...

[feinpus]

Bu kumaş imalat programında iplikler ile ilgili bir bölüm burada her dakika yeni bir iplik kaydı, stok bilgisi, transfer vs. şeyler var.

Yani mal geldi kayıt et.
Mal çıktı kayıt et.
Başka depoya taşındı kayıt et.
Mal miktarı değişti düzelt. //vs. Gibi işlemler yapılacak burada.

Depodaki iplikleri listele, Diğer depodakileri listele gibi Gridler veya raporlarım olacak.Ancak ürün tanımı ve bu ürünlerin alt tanımlarının fazla oluşu ve mal giriş çıkışının çok fazla olması nedeniyle paradoxta ben başka bir tablo kullanma yöntemini kullanıyordum.

Yani her tablo içinde 25bin kayıt var şimdilik bu tablolardan 6 tanesi içindeki bilgiler bana gerekli bir yerde göstermeliyim bunları.

Ama memory tablosu kullanarak hafızaya yüklenmek nekadar doğru olur bilemiyorum. Ayrıca daha öncede belirttiğim gibi bu veriler saniyelik değişiyor. Her seferinde son güncellemeyi en hızlı şekilde almak istiyorum kısaca.

Join veya union query yapmakta istemiyorum çünkü bir sorguda 6 tabloyuda açmak büyük zahmet.

Ama bu Sp lerde farklılık gösterirmi bilmiyorum.

View tabloları ise çalışma mantığını bilmiyorum anlatırsanız sevinirim. Eğer bir kere sorguyu çalıştırıp sadece değişiklik yapılan kayıtlarda yenileme yapıp tüm sorguyu tekrar çalıştırmıyorsa bence bu kullanılabilir.
Fakat her seferinde sql sorgusunu yapıyorsa diğer yöntemlerden bir farkı yok diye düşünüyorum ....

[ercere]

Yani mal geldi kayıt et.
Mal çıktı kayıt et.
Başka depoya taşındı kayıt et.
Mal miktarı değişti düzelt. //vs. Gibi işlemler yapılacak burada.

Bu yaptığınız işlemler bahsettiğiniz 6 tablo içindemi?. Şayet öyle ise
bütün bu işlemleri iki tabloda toplamayı niçin düşünmüyorsunuz.
1-ürün tablosu
2-Ürün hareket tablosu.
Böylece bu iki tablo ile sp ler ile istediğiniz raporu alabilir istediğiniz hareketi yapabilirsiniz.

[freeman35]

Öncelikle paradox (adı bile itici karmaşa) ile bu karmaşanın altından kalktıysan kafanda sakın büyütme FB ile gözün kapalı yapabilirsin.
view kullanma derim. Bende eskiden view kullanırdım. view larda join kullanılmazsa kayıt dahi yapabilirsin, ama dışarıdan parametre gönderemezsin. Bir rapor için view oluşturmaya debelenirken Mustafa ve Ahmet bunu SP le daha kolay yapabilirsin demişti ve ben o günden beri Fahrettin de saolsun herşeyi SP ile yapmaya çalışırım.
Avantaşları parametrik sorgular kullanabiliyorsun, 7-8 parametre gönderdiğim sorgularım var. 6 tane join demişsin 15 tane join im var abartığımı düşünün 10 dan aşağı sermayesini kurtarmaz deyin hızmı ? Bit table açılmasıyla yanı tabiki şuda var SP içine yaptırılacak işlemlerle doğru orantılı. ama genede şunu söyliyebilirim, Seramik vs satan bir müşterim var depo takibi için bir programımı kullanıyorlar, ortalama stok adedi 20,000 adet bun liste şeyle

Kod: Tümünü seç

stok kodu ||Giren Adet|| Çıkan Adet||KALAN|| Rez.Giren||Rez Çıkan||Rez Kalan||Kullanılabilinir||

herbiri sum ile alınan değerler ve herbir stok ki 20,000 adet . bu query nin açılış hız boş query yi açmak ile aynı. ama maalesef cxgrid kullandığım için 2 sn falan sürüyor ilk açılışı. Bu özel bir rapor değil faturada fişlerde vs tüm stok adı seçmeleri gerek heryerde açılıyor. Bunun için SP kullandım.

Önemli olan tek şey indexlerin doğru alanlar için verilmiş olmarı.

Ayrıca bende sonuçları bir table a yazma taraftarı değilim arada bir bilgi kopukluğu olduğunda sistem hassassa göçebilir, mesela bir kullanıcı listeyi açtı ve 1 adet görünüyo onu satarken diğer kullanıcı bunu sattıysa anlık raporlarda ise bu olasılık nerdeyse hiç yok denebilir. Şöyleki FB de olduğunu varsayarsak yukarıdaki örnekte eğer kullanıcı sattığını kaydettiğinde bir event gönderilir, diğer taraftaki kullanıcının query si saece açılıp kapanır yani refresh ettirilir. bunda hata riski yok çünkü diskteki reel var olan bilgilerin sonucu gösteriliyor.

Kolay gele

[feinpus]

Bu yaptığınız işlemler bahsettiğiniz 6 tablo içindemi?. Şayet öyle ise
bütün bu işlemleri iki tabloda toplamayı niçin düşünmüyorsunuz.
1-ürün tablosu
2-Ürün hareket tablosu.
Böylece bu iki tablo ile sp ler ile istediğiniz raporu alabilir istediğiniz hareketi yapabilirsiniz.[/quote]

Tabloları toplayamam çünkü hepsi ayrı formun tabloları bende üretim esnasında kullanılan iplik depo haraketlerini gözlemek istiyorum. Bizim şirkette ortalama günde 90bin kayıt giriliyor. Ama depo içinde 100 ile 500 adet filan gerekli bilgi kalıyor.

@freeman35,

Verdiğin tavsiyeler için teşekkür ederim. Sanırım SP ler ile deneyebilirim. Benim eski kayıtları FB ye geçirip bir test edeyim arasında nekadar fark var bakalım.