- Özel Başlık (Postbit)
- Silkroad Online
MaxiGuard Unique Kill Add Honor Point V2
- Konuyu Başlatan Thor
- Başlangıç tarihi
Bu forumdaki neredeyse bir çok üyeyin when case'ler le derdi ne anlamış değilim
Tamam siz tablodan çekin.Performans: CASE ifadesi, küçük ve sabit veri kümeleri için oldukça hızlı ve basit bir çözüm sunar. SQL sorgusunda sabit bir veri kümesi olduğu için ek bir tabloya erişim gerekmez, bu da küçük veri setleri için hızlı sonuçlar sağlayabilir.
Bu mantık ile 3-5 unique için if/else de iş görür ama kalkıp min 50 uniqueli bir pvp server açılacaksa tablodan çekmek daha mantıklı satır satır bütün uniqueleri caselemek gereksiz olur. Kaldı ki zaten backend te fazlasıyla queryler dönüyor burda yapacağımız kısayolun performansa çok katkısı olacağını sanmam modül sürümü eski ve 32bit yani kapasitesi zaten kısıtlı ona rağmen filter ile eklenen özellikler ortada ve çalışması için harcadığı işlem gücüde belliBu forumdaki neredeyse bir çok üyeyin when case'ler le derdi ne anlamış değilim
Performans: CASE ifadesi, küçük ve sabit veri kümeleri için oldukça hızlı ve basit bir çözüm sunar. SQL sorgusunda sabit bir veri kümesi olduğu için ek bir tabloya erişim gerekmez, bu da küçük veri setleri için hızlı sonuçlar sağlayabilir.
darboğazlık bir sürüme yığınla sistem yüklerken performansın dikkate alındığını sanmıyorum
Filter tarafında bir çok işlemi modullerden bağımsız yani karakter adı ve eventidsini alıp filtrelemisini filter üzerinden sql ile yapıyor bu ap ayrı bir konu. Daha önce magic popda da paylaştıgım gibi, eğer orada da altını çizdim max 15 20 verinin olduğu işlemlerde tablo oluşturmak bana gereksiz ugraş geliyor. Kodun performansa ihtiyacı yok bile zaten. Onun için prosedürden tabloya gidip geri gelmesine gerek yok. İçerde halledip çıkıyor, ki perfomans testinde de aynı veriler dönüyor. Dediğin gibi veri 15 20 den fazlaysa iş tabloya dönebilir.Bu mantık ile 3-5 unique için if/else de iş görür ama kalkıp min 50 uniqueli bir pvp server açılacaksa tablodan çekmek daha mantıklı satır satır bütün uniqueleri caselemek gereksiz olur. Kaldı ki zaten backend te fazlasıyla queryler dönüyor burda yapacağımız kısayolun performansa çok katkısı olacağını sanmam modül sürümü eski ve 32bit yani kapasitesi zaten kısıtlı ona rağmen filter ile eklenen özellikler ortada ve çalışması için harcadığı işlem gücüde belli
darboğazlık bir sürüme yığınla sistem yüklerken performansın dikkate alındığını sanmıyorum
Filter özellikleri ile SQL e ek işlem yükü verilmesi ve çalışma gücünün daha fazla artmasını kastettim. Yani kısaca SQL i yormak. Mesela çoğunlukla return scroll ile bir uptade yaparız ama her tp sonrasında GS SQL i çalıştırıyor. Gift box ekli bir oyunda karakter başına 100 scroll ile 50 karakterin bunu yaptığını bir düşün döngü gibi sürekli item/char info yu sql den almak için query çalıştıracak. Günümüz filter özellikleri de her tp sonrasında data_refresh yapıyor... daha fazla örnek vermeye gerek varmı
Oyunun Orjinal prosedürlerini ve Triggerlerini İnceledikten sonra Yaptığımız Döngüler Vb Dediğin Gibi Parşömenler Fazlasıyla Basit Kaçıyor Biz Düşünüyoruz Sql Yorulur Adamlar 2005 de Prosedürlerle Oyun Yönetmişler Özellikle İlk Filesleri ve Sql DataBaselerini İnceledinmi bilmiyorum ama Şuanki Dediğimiz gibi sql yorulur derdik..Filter özellikleri ile SQL e ek işlem yükü verilmesi ve çalışma gücünün daha fazla artmasını kastettim. Yani kısaca SQL i yormak. Mesela çoğunlukla return scroll ile bir uptade yaparız ama her tp sonrasında GS SQL i çalıştırıyor. Gift box ekli bir oyunda karakter başına 100 scroll ile 50 karakterin bunu yaptığını bir düşün döngü gibi sürekli item/char info yu sql den almak için query çalıştıracak. Günümüz filter özellikleri de her tp sonrasında data_refresh yapıyor... daha fazla örnek vermeye gerek varmı
Bu konuyu görüntüleyen kullanıcılar
Benzer konular
vSRO Çözüldü
GM Unique Kill Notice
Etiketler
- Etiketler
- honor honor puan maxiguard procedure unique honor