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

[mege]

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]

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]

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]

test sonuçları :

Advanced Data Generator 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).
Exec time: 0.02 s / 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
1.009.282 KAYIT VAR

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).
Exec time: 0.00 s / Fetch time: 5.42 s

ya 1 milyon kayıt içinde 26000 taneyi geri döndürüyor Exec time: 0.00 s

[freeman35]

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

Kod: Tümünü seç

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]

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]

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]

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

[mege]

İş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 varsa görüşelim üh artık buda varsa ortak yapalım işi