Firebird de Tablo Yapısı seçiminde kararsızlık

Firebird de Tablo Yapısı seçiminde kararsızlık

mege	19.02.2005 - 17:28:28
selamlar, paradoxtan firebirde(1.5.x - ibx- delphi7 ) geçirdiğim bi projem var. ( oha hala geçirmedinmi demeyin, çok işi vardı) tablo yapısıyla ilgili bir türlü karar veremediğim bir durum var. firebirdi kullanan arkadaşlara danışmak istedim. eski yapımda 2 tablom vardı, bu 2 tablo alanlar olarak tamamen aynı.(15 field ve çoğu integer,double falan filan) ilki (gün içinde ara ara 3er 5er max 2000 adet) verinin girdiği ve 5-10 dakika içinde işlem görüp , sonra işlem bitince arşiv amaçlı ikinci tabloma aktardığım bir yapı vardı. (stoktaki girdi çıktı gibi düşünebilirsiniz). tabi buda arşivde yılda 700 bin kusur kayıt yapar. neyse soruma geleyim. şimdi firebirdde bu iki tablou birleştirmeyi düşündüm. ilk önce mantıklı geldi. örneğin queryde sadece where status<>tamamlandı and ... diyip gün içindeki tamamlanmamış işlermleri çekecektim. tam yapmaya başladım şimdi aklıma acaba gereksiz yere vt yi kasacam yapmasammı acaba diye düşünmeye başladım. sizce bu tabloları birleştirsemmii birleştirmesemmi :) esasında birleştirmemek konusundaki tek çekincem, acaba fazla geç gelirmi queryler.? bi günkü işlemler için koca tablo yapısını tararmı bu firebird? veya şöyle yaparsan hiç hız problemin falan olmaz diye bi öneriniz varmı. teşekkürler. umarım anlatabilmişimdir.

mege	19.02.2005 - 17:33:05
master jeday KURI_TLJ nin seminerindeydim oyüzden kayıt saıysının problem olmayacağını biliyorum ancak sürekli (dakkada bir gibi ) bu yapının sorgulanması gerek. bi ara bu tablolar için memory tablo düşünmüştüm ama bu ara işlemdeki (tablodakilerin) dışardan da izlenmesi gerekiyor. yani bi yerde tutmak şart. :?

sadettinpolat	19.02.2005 - 18:44:17
gerekli indexleri tanımladıktan sonra hız konusunda problem çıkacağını sanmıyorum. eğer dediğiniz gibi yılda 700 bin kayıttan bahsediyorsak içiniz rahat olabilir. birleştirmenin tek dezavantajı duruma göre status = tamamlandı veya status = tamamlanmadı yazmak olabilir. bu bazen kafa karıştırabilir. :)

mege	19.02.2005 - 21:03:41
test sonuçları : http://www.delphiturkiye.com/forum/viewtopic.php?p=36540#36540 i kurdım ve tabloma bağladım ve teste aldım. ( trial versiyonda bir seferda max 10000 kayıt üretebiliyor) ilk önce bi ayarını gözden kaçırmışım. 1000 kayıtta bi transaction çekecek şekilde ilk denememi yaptım gözüm yaşardı :) 20:44:30: Started. 20:44:30: Preparing for relation "ARSIV". 20:44:30: Starting 10000 rows for relation "ARSIV". 20:44:34: Inserted 10000 of 10000 rows for relation "ARSIV". 20:44:34: Finished. sonra baktımki bu benim yapıya uymaz. sonuçta ben her kayıttan sonra kesin kaydedicem. ayarlardan her kayda özel transaction yaptım yani 10000 transaction 20:45:09: Started. 20:45:09: Preparing for relation "ARSIV". 20:45:09: Starting 10000 rows for relation "ARSIV". 20:45:27: Inserted 10000 of 10000 rows for relation "ARSIV". 20:45:28: Finished. eh buda süper sayılır :) 19 saniyede 10000 kayıt. dataları üürettikten (124000 kayıt oldu) sonra query analizer ile (mitec in) bikaç query denemesi yaptım. firebird cevap süreleri: şu ana kadar 124000 kayıt var max query si : MAX INTEGER -------------- 1999 1 row(s) fetched (1 row(s) listed). Exec time: 0.30 s / Fetch time: 0.00 s sum query si: SUM DOUBLE PRECISION --------------------------- 12031678215.4974 1 row(s) fetched (1 row(s) listed). Exec time: 0.30 s / Fetch time: 0.00 s COUNT INTEGER -------------- 124282 1 row(s) fetched (1 row(s) listed). Exec time: 0.30 s / Fetch time: 0.00 s bide epey kayıt getiren bi query select * from arsiv where zaturzuturfield=5 3148 row(s) fetched (3148 row(s) listed). :7ffa90ccea/ Fetch time: 0.64 s sanırım pek endişem kalmadı hızla ilgili? peki başka ne olabilir? yani yapının doğruluğuyla ilgili soruyorum. daha önce stok tablolarında giriş çıkışların beraber tutulması daha iyi denmiş genelde. bide 1 milyon kayıtla deneyeyim bakayım ne olacak :) data.gdb 176,681 kb [u:7ffa90ccea]1.009.282 KAYIT VAR[/u:7ffa90ccea] select max(toplanabilirdoublebifield) from arsiv MAX INTEGER -------------- 1999 1 row(s) fetched (1 row(s) listed). Exec time: 2.45 s / Fetch time: 0.00 s select sum(toplanabilirdoublebifield) from arsiv SUM DOUBLE PRECISION --------------------------- 100503292314.793 1 row(s) fetched (1 row(s) listed). Exec time: 2.49 s / Fetch time: 0.00 s select count(toplanabilirdoublebifield) from arsiv COUNT INTEGER -------------- 1009282 1 row(s) fetched (1 row(s) listed). Exec time: 2.44 s / Fetch time: 0.00 s select * from arsiv where isteofield=5 26013 row(s) fetched (26013 row(s) listed). :7ffa90ccea ya 1 milyon kayıt içinde 26000 taneyi geri döndürüyor Exec time: 0.00 s :? :) :D

freeman35	21.02.2005 - 16:52:27
bence aktarma yapmana gerek yok. Aktarıldı fieldı yerine goster gösterme gibi bir field kullanabilirsin yani isim değişik. sonuçta herzaman query kullanıcaksın yani kayıt yapıcağın query select * from hebelehubele where goster = 1 order by PRKEY bu şekilde kullanırsan yada buna benzer bir şekilde kullanırsan 2 bir table mantıksızlaşıyor yani gereksiz yere kayıt aktarmış olursun. burandom kayıt işlemlerinde çok küçük sapmalar olabilir sebebi arka arkaya yazdırıyorsun, dolayısıyla db nin page file ları diske ard arda yazılıyor yani %99 arda arda :) ama kullanım sırasında bu olasılık çok düşük ve file defrag etmek gerekebilir. bu performansı ne kadar etkiler dersen sanırım en kötü 1-2 sn :) tabi en kötüsü. sum vs gibi işlemlerde kullanıcağın field lara index vermeyi unutma, yani ben kullanacağım her field a index veriyorum açıkçası. buda performans artışı sağlıyor. kolay gele

mege	21.02.2005 - 18:43:36
evet abi başta bende bunu düşündümde işte bi ara içime bi kurt düştü. acaba doğrumu yapıyorum diye. sanırım pek bi problem çıkmaz. sonuçta işlemdeki kayıt sayısı aynı anda 20-30 u geçmez zaten. bunlarında hepsini aynı anda fetch yapmayacağım için sürede öyle bikaç saniye sürmez dediğiniz gibi. sum süreside pek önemli değil, rapor alan beklesinde, iş yapan adam beklemesin tek önemli kısım burası. burada saniyeler sayıldığı için. neyse teşekkürler

Kuri_YJ	22.02.2005 - 08:42:26
Selamlar, Mege ne diyeyim kendin sormuş kendin çözmüşsün :) Performans elde etmek istiyorsan, özellikle iki konuya dikkat edersen (index ile ilgili iki konuya) sonrası peşinden gelir. İşte püf noktaları, 1. Az tekrar eden veriyi index yapında öne koy. Yani diyelim Tarih, Çalışılan Firma No, Müşteri No, Fatura No ve Çalışma Yılı gibi alanlardan oluşmuş bir indexe ihtiyaç duyuyorsun, bunu index oluştururken, Çalışma Yılı ; Çalışılan Firma No ; Tarih ; Müşteri No ; Fatura No şeklinde bir index oluşturursan, max. hızı elde edersin (Bu fieldlar ile) çünkü en az değişik gelme olasılığı olan alandan, en çok değişik gelme olasılığı olan alana doğru yapılandırılmış indexlerde Server'lar max. erişim hızını elde ederler. 2. Bir de aggragate kullanacaksan özellikle MAX aggragate'ini, MAX'ını çektiğin alan için DESC bir index tanımlamalısın. MAX gibi son değere erişmek isteyen aggragate'lerde DESC index performansın zirvesine çıkarır. Bu temel felsefe ile, oluşturacağın indexleri ve mümkünse Query'lerin performanslarını Analayzer (DBWorkbench'de) var bu özelik. Test et, bazen ummadık taş baş yarabilir. Kolay Gelsin.

hdayi	22.02.2005 - 09:20:34
:D :D :D mege ödeştik, benim de böyle bir problemim vardı. İşlemi bitmiş kayıtları Başka bir tabloda mı tutsam diyorum. Aldım cevabımı Kolay Gelsin... Not: Aynı programı yapıyor olmayalım :P

mege	22.02.2005 - 09:43:47
İşte püf noktaları, 1. Az tekrar eden veriyi index yapında öne koy. .... 2. Bir de aggragate kullanacaksan özellikle MAX aggragate'ini, MAX'ını çektiğin alan için DESC bir index tanımlamalısın. MAX gibi son değere erişmek isteyen aggragate'lerde DESC index performansın zirvesine çıkarır. @Kuri_TLJ çook teşekkürler. bu detaylara dikkat etmemiştim ama max ı çok kullandığımdan iki önerinizde işimi çok hızlandıracak gibi. teşekkürler. tekrar indexleyip biras daha test edeyim. Not: Aynı programı yapıyor olmayalım :p valla abi unicode varmı işin içinde :D varsa görüşelim :P üh artık buda varsa ortak yapalım işi

NOT : Bu sayfa google'un siteyi indekslemesi içindir. www.delphiturkiye.com/forum/ adresini kullanınız!
1998-2006 www.delphiturkiye.com