Herkese selamlar,
Undefined arkadaşımızı tebrik ediyorum. Ne yazık ki bu tür fikirleri ortaya atabilen kişi çok az, yada ben az rastladım. Ben DOS'tan örnek vererek başlamak istiyorum.
DOS'ta FAT'de (örneğin 1.44 diskte 80 sektör galiba hay Allah tam rakamını hatırlayamıyorum, kocadık artık kocadıııık... :)  )
vardı. Biz Key disketler yapardık program kopyalanmasın diye. DOS interrupt'ı ile 81. sektöre format atar birşeyler yazardık. Bu disket kopyalanamaz olurdu :)
Şimdi, şimdiki DB'ler Tek bir file halinde duruyor zaten :) Onlarda sürekli birbirini takip edr biçimde yazılıyor (Genelde) eğer bir fragmantasyon olursa Defrag gibi yazılımlarla bunlar bir araya getiriliyor ve DB planlamasında DB boyut büyümesini doğru şekilde tahminleyip verirseniz bu kayıplar minimuma iniyor. Sistem alt kısma (low-level'a indikçe) hızlanıyor ama tekrar eden işler sebeiyle üst tarafta yavaşlamaya neden oluyor.
Yazdıklarınızı (hekesin yazdıklarını) okudum herkes bildiği doğruları paylaşıyor. Ne güzel ! Bilgi ve sevgi paylaşıldıkça büyür, üzüntü keder hüzün korku paylaşıldıkça azalır :)
Sorularına bildiğim kadarı ile yanıt vereyim,
S : Transactionın karışıklılığa yol açmazmı ?
C : Açmaz yıllardır kullanılan bir yöntem ve problem oluşmuyor (Microsoft'ta oluyor, onlar olmuyor diyor ama oluyor )
S : Mesela commit olmamış bir stok çıkışı depodaki malların fazla gösterilmesine sebep olmazmı ?
C : Olmaz çünkü normalde senin erişme mantığına, ve Lock mantığına göre değişir. Eğer Lock mantığın Table Lock ise ve Exclusive ise senin transaction'ın başladığında o table'ı kimse açamaz/okuyamaz, işlem yapamaz bu sebeple transaction kapanana kadar kimse erişemez ve bekler.
S :Yoksa mantıksal düzeyde mal çıkışı olduğu varsayılırmı ?
C : Bkz. Transaction Isolation Level ve Locking işlemleri.
S : Varsayılsa bile rollback yapıldımı yine karışıklık çıkmazmı ?
C : Çıkmaz çünkü start transaction dendiği anda sistem table'ın o andaki durumunun bir kopyasını saklar (mantıksal olarak saklar, aslında senin yaptığın işlemler başka yere yazılır.)
S : Ayrıca bu işin ne kadarı client'a ne kadarı server'a düşer ?
C : Transaction'da client'a hiç iş düşmez client durmadan yaz çiz bul ara ekle filan der, o sırada Server deli gibi koşuşturur :)
S : Hangi sıklıkta commit yapılması lazım ?
C : Tamamen yaptığın işe bağlı :) Bazen işin bitene kadar yapmazsın, bazen ise işlemleri bölümlerdirirsin bu şekilde yaparsın. Örneğin bir müşteri için bir takım ödeme planı oluşturup, eşleştirme yapacaksın. Bu durumda kimsenin o müşteriye ait bilgilerini ellememesi gerekir. Bu durumda transaction müşterinin son kaydı yapılana kadar kesilmemesi gerekir. Ancak bunu bin tane müşteriye uygulayacaksan, diğer kullanıcılara nefes almaları için fırsat tanıman gerekir. Bu sebeple her müşterinin işi bittiğinde commit deyip bir sonraki müşteriye geçerken tekrar start transaction demen gerekir.
S : Sıklık süresini belirleyen kriterler nedir ?
C : Bkz. üst taraftaki açıklamalar.
S : Bu sorunlarla karşılaştıysanız nasıl çözüm yolları geliştirdiniz ?
C : Allah Allah ne taklalar attık :) Öğrenene kadarda canımız çıkmadı değil hani ve amacımızda bu sorunlarla karşılaşanlara bir yardım eli uzatmak.
Tavsiyem bu fikrinizi biraz daha farklı yönlerde pişirebilmek ben de düşüneceğim. Belki bir farklı yön bulabiliriz. Sanırım bu listedeki aktif arkadaşlar da eminim ki düşünecekler. Bu fikri veya bu fikirden doğan diğer fikirler bir yerlerde bizlere yardımcı olacak.
Sevgiler,
Kolay gelsin. |
Ama genel bir yaklaşımla soruları yanıtlarsanız sevinirim.( Yani Recep abinin bahsettiği gibi sorulara Süleyman Demirel'in okuma taktikleriyle yaklaşabilirsiniz :D )