Çok Fazla Sql Kullanmak

[magnet00]

yapılan işlemlerin çoğuna mysql sorgusu çalıştırıyorum. bunun performans kaybı dışında bir zararı var mı , var ise bunun doğru kullanımı nedir ?

[Krips Je]

Yaptığın her işlemde MySQL sorgusu çalıştırmak uzun vadede performans kaybına sebep olur. Hem sunucuyu yorarsın hem de gereksiz sorgu trafiği oluşur. Bu da oyuncu sayısı arttıkça lag ve gecikmeye yol açabilir. En doğrusu, sık sık değişmeyen verileri bellekte tutup belirli aralıklarla veritabanına yazmaktır. Gereksiz yere sürekli SELECT ya da UPDATE atmak yerine, planlı veri yönetimi daha sağlıklıdır.

[Backup]

Kullandığın sorguya göre değişir. Verimsiz sorgu = ram tüketimi olarak geri döner sana. Ayrıca yukarda @Krips Je 'nin görüşüne katılmıyorum. Bir veri değiştiğinde, saklandığı yerdeki değer ile aynı olmalı ve eşitlenen değişken temizlenmelidir. Aksi takdirde değişkenler bellekte çok daha fazla yer kaplayacaktır. CRUD işlemleri dinamik bir yapı ile veritabanına aktarılmalıdır.

Sorguları optimize etmek için Primary Key'ler üzerinden çalışabilirsin. Birincil anahtar otomatikmen indexleneceği için sorgu performansına doğrudan etki eder. Örneğin users tablonda id primary key name varchar olduğunu düşünürsek sorgunu aşağıdaki şekilde yapmalısın.

Doğru Yöntem

PAWN Kodu: Seç

SELECT * FROM users WHERE id = 5;Yanlış Yöntem

PAWN Kodu: Seç

SELECT * FROM users WHERE name = 'Backup';

Ayrıca pawn dilinde cache ile veri çektikten sonra cache_delete(); fonksiyonu ile bellek temizliği yapman önemli bir husustur.


Koşullu bir durumu kontrol etmek istiyorsanız bunu SQL üzerinde yapın. Örneğin 1000'den büyük skorlu en yüksek 10 kişiyi getirecekseniz bunu SQL'de şartlamanız daha doğru olacaktır.

Doğru Yöntem

PAWN Kodu: Seç

SELECT Name, Score FROM users WHERE Score > 1000 ORDER BY Score DESC LIMIT 10
Yanlış Yöntem

PAWN Kodu: Seç

SELECT * FROM users ile tüm veriyi  çekip döngüde dönerken kontrol yapmak yanlış olacaktır.

[ayazcik]

PAWN Kodu: Seç

SELECT Orneksutun FROM users WHERE id = 1;
Bu kullanımlada sadece belirtilen sütunu çekersin, cacheye bir katkısı olabilir bana kalırsa sorguların ram vesaire etkisinin çok olduğunu düşünmüyorum tabi ne kadar büyük sorgular çektiğine bağlı büyük bir veritabanında bir sürü potansiyel çıkarabilcek bir sorgu yaparsan haliyle düşüş yaşarsın ama burda xampp gibi programlardaki ayarlarla kendi veritabanınıda performansa göre ayarlayabilirsin buffer size vb. (yanlış hatırlıyor olabilirim) kısacası ahım şahım şeyler döndürmedikçe ve cacheyi sildiğin sürece ve sorguları optimize bir şekilde yolladığında primary key vb. (çünkü primary key çoğaltılamaz tek birisine özeldir ve sorguyu direk çekebilir) adla arama yaparsan bu isime benzeyen birisinin olma ihtimali ve varchar arattığını göz önüne alırsak haliyle yavaş olacaktır.

Cache_num_rows gibi sadece sorguya uyuşan sonuçları çekeceğiniz zamanda;

PAWN Kodu: Seç

SELECT NULL FROM users WHERE id = 1;gibi yapabilirsiniz buda etkili olabilir ama bunu sadece sorguya uyuşan verinin sayısını göstermek veya kullanmak için yazmanız gerektiğini unutmayın

[Krips Je]

Kullandığın sorguya göre değişir. Verimsiz sorgu = ram tüketimi olarak geri döner sana. Ayrıca yukarda @Krips Je 'nin görüşüne katılmıyorum. Bir veri değiştiğinde, saklandığı yerdeki değer ile aynı olmalı ve eşitlenen değişken temizlenmelidir. Aksi takdirde değişkenler bellekte çok daha fazla yer kaplayacaktır. CRUD işlemleri dinamik bir yapı ile veritabanına aktarılmalıdır.

Eyvallah dostum, görüşüne saygım sonsuz. Herkesin sistemi, yaklaşımı farklı olabilir, bu çok doğal. Benim anlatmak istediğim aslında şu her veri değişiminde anlık olarak sorgu atmak, özellikle çok oyunculu ortamlarda zamanla yük bindiriyor. Bu durum belki az oyunculu sunucularda hissedilmiyor ama sistem büyüdükçe veya aynı anda onlarca oyuncu veri alışverişi yaptığında fark yaratmaya başlıyor.

Ben de tüm veriyi cache de tutalım, DB yi unutsunlar demiyorum. Zaten dinamik verilerde anlık kayıtlar elbette gerekebilir. Ama örnek olarak her 5 saniyede bir para, seviye, pozisyon ve bir çok vs. sürekli UPDATE atmak yerine, bunu belirli zamanlarda toplu yapmak veya değişiklik olduğunda tetiklemek sistemin sağlığı açısından daha verimli oluyor.

Zaten senin paylaştığın örneklerde de verimsiz sorgu dan kaçınmanın yolları gösterilmiş, ben de aynı bakış açısındayım. Sadece bazı arkadaşlar her küçük işlemde bile direkt veritabanına dönmeyi alışkanlık haline getirince uzun vadede bu sıkıntıya dönüşebiliyor.

Yani kısacası anlık ihtiyaçlarda DB yi kullan, ama sık değişmeyen ya da yoğun kullanılan verilerde cache veya planlı kayıt mantığı daha sağlıklı. Ortada buluşabileceğimiz nokta bence bu.

[Backup]

Ben de tüm veriyi cache de tutalım, DB yi unutsunlar demiyorum. Zaten dinamik verilerde anlık kayıtlar elbette gerekebilir. Ama örnek olarak her 5 saniyede bir para, seviye, pozisyon ve bir çok vs. sürekli UPDATE atmak yerine, bunu belirli zamanlarda toplu yapmak veya değişiklik olduğunda tetiklemek sistemin sağlığı açısından daha verimli oluyor.



Yani kısacası anlık ihtiyaçlarda DB yi kullan, ama sık değişmeyen ya da yoğun kullanılan verilerde cache veya planlı kayıt mantığı daha sağlıklı. Ortada buluşabileceğimiz nokta bence bu.

Bu iki cümlene sonuna kadar katılıyorum, değişiklik yapıldığında tetiklenmesi daha doğru olacaktır. Örneğin oyuncunun oyundan çıktığı pozisyonu her saniye kaydetmek yerine OnPlayerDisconnect eventinde veritabanına yazılabilir.  Ani sunucu kapanmalarına karşın da her interior-exterior değiştiğinde son pozisyon kaydedilebilir gibi extra yapılar tavsiye olunur.

Ancak canlı harita olarak her oyuncunun pozisyonunu kaydedip bunu listelemek istiyorsan Socket yardımı ile anlık veri haberleşmesi yapabilirsin. Burada da ilişkisel veritabanına ihtiyacın bulunmaz. NoSQL database ile yapabilirsin yada socket vasıtası ile bir port üzerinden client-server haberleşmesini gerçekleştirebilirsin.


CRUD işlemlerinde senaryo gereği DB işlemlerini en optimum seviyede tutmak en doğrusu olacaktır

[magnet00]

Ben de tüm veriyi cache de tutalım, DB yi unutsunlar demiyorum. Zaten dinamik verilerde anlık kayıtlar elbette gerekebilir. Ama örnek olarak her 5 saniyede bir para, seviye, pozisyon ve bir çok vs. sürekli UPDATE atmak yerine, bunu belirli zamanlarda toplu yapmak veya değişiklik olduğunda tetiklemek sistemin sağlığı açısından daha verimli oluyor.



Yani kısacası anlık ihtiyaçlarda DB yi kullan, ama sık değişmeyen ya da yoğun kullanılan verilerde cache veya planlı kayıt mantığı daha sağlıklı. Ortada buluşabileceğimiz nokta bence bu.

Bu iki cümlene sonuna kadar katılıyorum, değişiklik yapıldığında tetiklenmesi daha doğru olacaktır. Örneğin oyuncunun oyundan çıktığı pozisyonu her saniye kaydetmek yerine OnPlayerDisconnect eventinde veritabanına yazılabilir.  Ani sunucu kapanmalarına karşın da her interior-exterior değiştiğinde son pozisyon kaydedilebilir gibi extra yapılar tavsiye olunur.

Ancak canlı harita olarak her oyuncunun pozisyonunu kaydedip bunu listelemek istiyorsan Socket yardımı ile anlık veri haberleşmesi yapabilirsin. Burada da ilişkisel veritabanına ihtiyacın bulunmaz. NoSQL database ile yapabilirsin yada socket vasıtası ile bir port üzerinden client-server haberleşmesini gerçekleştirebilirsin.


CRUD işlemlerinde senaryo gereği DB işlemlerini en optimum seviyede tutmak en doğrusu olacaktır

Kullandığın sorguya göre değişir. Verimsiz sorgu = ram tüketimi olarak geri döner sana. Ayrıca yukarda @Krips Je 'nin görüşüne katılmıyorum. Bir veri değiştiğinde, saklandığı yerdeki değer ile aynı olmalı ve eşitlenen değişken temizlenmelidir. Aksi takdirde değişkenler bellekte çok daha fazla yer kaplayacaktır. CRUD işlemleri dinamik bir yapı ile veritabanına aktarılmalıdır.

Eyvallah dostum, görüşüne saygım sonsuz. Herkesin sistemi, yaklaşımı farklı olabilir, bu çok doğal. Benim anlatmak istediğim aslında şu her veri değişiminde anlık olarak sorgu atmak, özellikle çok oyunculu ortamlarda zamanla yük bindiriyor. Bu durum belki az oyunculu sunucularda hissedilmiyor ama sistem büyüdükçe veya aynı anda onlarca oyuncu veri alışverişi yaptığında fark yaratmaya başlıyor.

Ben de tüm veriyi cache de tutalım, DB yi unutsunlar demiyorum. Zaten dinamik verilerde anlık kayıtlar elbette gerekebilir. Ama örnek olarak her 5 saniyede bir para, seviye, pozisyon ve bir çok vs. sürekli UPDATE atmak yerine, bunu belirli zamanlarda toplu yapmak veya değişiklik olduğunda tetiklemek sistemin sağlığı açısından daha verimli oluyor.

Zaten senin paylaştığın örneklerde de verimsiz sorgu dan kaçınmanın yolları gösterilmiş, ben de aynı bakış açısındayım. Sadece bazı arkadaşlar her küçük işlemde bile direkt veritabanına dönmeyi alışkanlık haline getirince uzun vadede bu sıkıntıya dönüşebiliyor.

Yani kısacası anlık ihtiyaçlarda DB yi kullan, ama sık değişmeyen ya da yoğun kullanılan verilerde cache veya planlı kayıt mantığı daha sağlıklı. Ortada buluşabileceğimiz nokta bence bu.

PAWN Kodu: Seç

SELECT Orneksutun FROM users WHERE id = 1;
Bu kullanımlada sadece belirtilen sütunu çekersin, cacheye bir katkısı olabilir bana kalırsa sorguların ram vesaire etkisinin çok olduğunu düşünmüyorum tabi ne kadar büyük sorgular çektiğine bağlı büyük bir veritabanında bir sürü potansiyel çıkarabilcek bir sorgu yaparsan haliyle düşüş yaşarsın ama burda xampp gibi programlardaki ayarlarla kendi veritabanınıda performansa göre ayarlayabilirsin buffer size vb. (yanlış hatırlıyor olabilirim) kısacası ahım şahım şeyler döndürmedikçe ve cacheyi sildiğin sürece ve sorguları optimize bir şekilde yolladığında primary key vb. (çünkü primary key çoğaltılamaz tek birisine özeldir ve sorguyu direk çekebilir) adla arama yaparsan bu isime benzeyen birisinin olma ihtimali ve varchar arattığını göz önüne alırsak haliyle yavaş olacaktır.

Cache_num_rows gibi sadece sorguya uyuşan sonuçları çekeceğiniz zamanda;

PAWN Kodu: Seç

SELECT NULL FROM users WHERE id = 1;gibi yapabilirsiniz buda etkili olabilir ama bunu sadece sorguya uyuşan verinin sayısını göstermek veya kullanmak için yazmanız gerektiğini unutmayın

Kullandığın sorguya göre değişir. Verimsiz sorgu = ram tüketimi olarak geri döner sana. Ayrıca yukarda @Krips Je 'nin görüşüne katılmıyorum. Bir veri değiştiğinde, saklandığı yerdeki değer ile aynı olmalı ve eşitlenen değişken temizlenmelidir. Aksi takdirde değişkenler bellekte çok daha fazla yer kaplayacaktır. CRUD işlemleri dinamik bir yapı ile veritabanına aktarılmalıdır.

Sorguları optimize etmek için Primary Key'ler üzerinden çalışabilirsin. Birincil anahtar otomatikmen indexleneceği için sorgu performansına doğrudan etki eder. Örneğin users tablonda id primary key name varchar olduğunu düşünürsek sorgunu aşağıdaki şekilde yapmalısın.

Doğru Yöntem

PAWN Kodu: Seç

SELECT * FROM users WHERE id = 5;Yanlış Yöntem

PAWN Kodu: Seç

SELECT * FROM users WHERE name = 'Backup';

Ayrıca pawn dilinde cache ile veri çektikten sonra cache_delete(); fonksiyonu ile bellek temizliği yapman önemli bir husustur.


Koşullu bir durumu kontrol etmek istiyorsanız bunu SQL üzerinde yapın. Örneğin 1000'den büyük skorlu en yüksek 10 kişiyi getirecekseniz bunu SQL'de şartlamanız daha doğru olacaktır.

Doğru Yöntem

PAWN Kodu: Seç

SELECT Name, Score FROM users WHERE Score > 1000 ORDER BY Score DESC LIMIT 10
Yanlış Yöntem

PAWN Kodu: Seç

SELECT * FROM users ile tüm veriyi  çekip döngüde dönerken kontrol yapmak yanlış olacaktır.

Yaptığın her işlemde MySQL sorgusu çalıştırmak uzun vadede performans kaybına sebep olur. Hem sunucuyu yorarsın hem de gereksiz sorgu trafiği oluşur. Bu da oyuncu sayısı arttıkça lag ve gecikmeye yol açabilir. En doğrusu, sık sık değişmeyen verileri bellekte tutup belirli aralıklarla veritabanına yazmaktır. Gereksiz yere sürekli SELECT ya da UPDATE atmak yerine, planlı veri yönetimi daha sağlıklıdır.

Değerli Yanıtlarınız İçin Teşekkür Ediyorum Öncelikle , Zaten Daha önce veritabanı ile çok çalıştığım için bu tarz şeylere hakimim ancak bazen veritabanlarımda bu yüzden çökmeler oldu , veri kaybı yaşadım acaba burdada yaşar mıyım diye merak ettim. tabiki oyuncu her hareket ettiğinde veri tabanı güncellenmez ancak veritabanına başka oyuncuların verileride kaydedileceğinden aynı anda biraz sorgunun çalışması gerekir anladıgım kadarıyla buda bir sorun yaratmayacaktır.

[magnet00]

PAWN Kodu: Seç

CMD:cetekur(playerid, params[]){
if(game_players[playerid][pCeteID] != 0) return SendClientMessage(playerid,-1,"[!] Zaten Bir Çeteniz Var Önce Oradan Ayrılın.");
if(game_players[playerid][pRobScore]<1000 && game_players[playerid][pMoney] < 2500000) return SendClientMessage(playerid,-1,"[!] Çete Kurmak İçin En Az 1000 Hırsız Skorun Ve Üstünde En Az 2,500,000 $ Olması Lazım.");
new cadi[64] , bosid ,str[256];
if(sscanf(params , "s[64]" , cadi)) return SendClientMessage(playerid , -1 , "[BİLGİ] Kullanım : /cetekur çete_adı");
for(new i =0;i<MAX_CETE_SAYISI;i++){
if(ceteler[i][cID] == 0){
bosid = i;
break;
}
}
format(str,sizeof(str),"INSERT INTO `ceteler` (`ceteSahibi`, `ceteAdi`, `ceteKasasi`) VALUES (%d,'%s',%d)",game_players[playerid][pID],cadi,0);
mysql_query(mysqlC,str);

format(str,sizeof(str),"SELECT * FROM ceteler ORDER BY ceteID DESC LIMIT 1");
mysql_query(mysqlC,str);

cache_get_value_name_int(0,"ceteID",ceteler[bosid][cID]);
ceteler[bosid][cOwner] = game_players[playerid][pID];
format(ceteler[bosid][cName] , 64 , cadi);
ceteler[bosid][cMoney] = 0;

format(str,sizeof(str),"INSERT INTO `cete_yetkileri` (`cID`, `yLevel`, `yName`) VALUES (%d,%d,'%s')",ceteler[bosid][cID],1,"UYE");
mysql_query(mysqlC,str);

format(str,sizeof(str),"INSERT INTO `cete_yetkileri` (`cID`, `yLevel`, `yName`) VALUES (%d,%d,'%s')",ceteler[bosid][cID],10,"KURUCU");
mysql_query(mysqlC,str);

format(str,sizeof(str),"SELECT * FROM cete_yetkileri ORDER BY yID DESC LIMIT 1");
mysql_query(mysqlC,str);
cache_get_value_name_int(0,"yID",game_players[playerid][pCeteYetkiID]);

return 1;
}

Buradaki Kullanım Hakkında Yorumunuz Nedir , Tek Sefere Mahsus Bir Kaç Sorgu Atılıyor Bunlar Değişkenlere Atılıyor Ve Bu Değişkenler Üzerinden Kontrol Ediliyor , En Son Oyuncu Cıkarken Oyuncu Verileri Kaydediliyor Cache_delete şuan Kullanmadım Onuda Ekleyeceğim

[Krips Je]

PAWN Kodu: Seç

CMD:cetekur(playerid, params[]){
if(game_players[playerid][pCeteID] != 0) return SendClientMessage(playerid,-1,"[!] Zaten Bir Çeteniz Var Önce Oradan Ayrılın.");
if(game_players[playerid][pRobScore]<1000 && game_players[playerid][pMoney] < 2500000) return SendClientMessage(playerid,-1,"[!] Çete Kurmak İçin En Az 1000 Hırsız Skorun Ve Üstünde En Az 2,500,000 $ Olması Lazım.");
new cadi[64] , bosid ,str[256];
if(sscanf(params , "s[64]" , cadi)) return SendClientMessage(playerid , -1 , "[BİLGİ] Kullanım : /cetekur çete_adı");
for(new i =0;i<MAX_CETE_SAYISI;i++){
if(ceteler[i][cID] == 0){
bosid = i;
break;
}
}
format(str,sizeof(str),"INSERT INTO `ceteler` (`ceteSahibi`, `ceteAdi`, `ceteKasasi`) VALUES (%d,'%s',%d)",game_players[playerid][pID],cadi,0);
mysql_query(mysqlC,str);

format(str,sizeof(str),"SELECT * FROM ceteler ORDER BY ceteID DESC LIMIT 1");
mysql_query(mysqlC,str);

cache_get_value_name_int(0,"ceteID",ceteler[bosid][cID]);
ceteler[bosid][cOwner] = game_players[playerid][pID];
format(ceteler[bosid][cName] , 64 , cadi);
ceteler[bosid][cMoney] = 0;

format(str,sizeof(str),"INSERT INTO `cete_yetkileri` (`cID`, `yLevel`, `yName`) VALUES (%d,%d,'%s')",ceteler[bosid][cID],1,"UYE");
mysql_query(mysqlC,str);

format(str,sizeof(str),"INSERT INTO `cete_yetkileri` (`cID`, `yLevel`, `yName`) VALUES (%d,%d,'%s')",ceteler[bosid][cID],10,"KURUCU");
mysql_query(mysqlC,str);

format(str,sizeof(str),"SELECT * FROM cete_yetkileri ORDER BY yID DESC LIMIT 1");
mysql_query(mysqlC,str);
cache_get_value_name_int(0,"yID",game_players[playerid][pCeteYetkiID]);

return 1;
}

Buradaki Kullanım Hakkında Yorumunuz Nedir , Tek Sefere Mahsus Bir Kaç Sorgu Atılıyor Bunlar Değişkenlere Atılıyor Ve Bu Değişkenler Üzerinden Kontrol Ediliyor , En Son Oyuncu Cıkarken Oyuncu Verileri Kaydediliyor Cache_delete şuan Kullanmadım Onuda Ekleyeceğim

telefonayım baktım attığın koda, sistem genel olarak mantıklı ilerliyor, tek seferlik sorgularla veri alıp değişkenlere atamak sade ve işlevsel bir yöntem olmuş.

Ancak bazı noktalarda küçük geliştirmeler yapabilirsin

Yeni oluşturulan çetenin id sini almak için tekrar SELECT sorgusu atmak yerine mysql_insert_id() fonksiyonunu kullanabilirsin, bu hem daha performanslı hem de daha doğru bir yöntemdir.

Yaptığın SELECT sorgularından sonra cache_delete kullanmaman uzun vadede bellek tüketimini artırabilir. Özellikle slot sayısı yüksek sunucularda bu durum FPS düşüşü ve veri güncellemelerinde gecikmeye neden olabilir.

Sorgulardan sonra hata kontrolü yapmaman olası bir SQL hatasını fark etmeyi zorlaştırır. mysql_errno() gibi fonksiyonlarla hataları yakalayıp loglaman daha güvenli bir sistem sağlar.

Tekrar eden SQL bloklarını fonksiyonlaştırarak kodun okunabilirliğini ve sürdürülebilirliğini artırabilirsin.

Genel olarak temel yapı doğru, sadece ufak dokunuşlarla daha temiz, performanslı ve hataya dayanıklı bir sistem elde edebilirsin.

[magnet00]

PAWN Kodu: Seç

CMD:cetekur(playerid, params[]){
if(game_players[playerid][pCeteID] != 0) return SendClientMessage(playerid,-1,"[!] Zaten Bir Çeteniz Var Önce Oradan Ayrılın.");
if(game_players[playerid][pRobScore]<1000 && game_players[playerid][pMoney] < 2500000) return SendClientMessage(playerid,-1,"[!] Çete Kurmak İçin En Az 1000 Hırsız Skorun Ve Üstünde En Az 2,500,000 $ Olması Lazım.");
new cadi[64] , bosid ,str[256];
if(sscanf(params , "s[64]" , cadi)) return SendClientMessage(playerid , -1 , "[BİLGİ] Kullanım : /cetekur çete_adı");
for(new i =0;i<MAX_CETE_SAYISI;i++){
if(ceteler[i][cID] == 0){
bosid = i;
break;
}
}
format(str,sizeof(str),"INSERT INTO `ceteler` (`ceteSahibi`, `ceteAdi`, `ceteKasasi`) VALUES (%d,'%s',%d)",game_players[playerid][pID],cadi,0);
mysql_query(mysqlC,str);

format(str,sizeof(str),"SELECT * FROM ceteler ORDER BY ceteID DESC LIMIT 1");
mysql_query(mysqlC,str);

cache_get_value_name_int(0,"ceteID",ceteler[bosid][cID]);
ceteler[bosid][cOwner] = game_players[playerid][pID];
format(ceteler[bosid][cName] , 64 , cadi);
ceteler[bosid][cMoney] = 0;

format(str,sizeof(str),"INSERT INTO `cete_yetkileri` (`cID`, `yLevel`, `yName`) VALUES (%d,%d,'%s')",ceteler[bosid][cID],1,"UYE");
mysql_query(mysqlC,str);

format(str,sizeof(str),"INSERT INTO `cete_yetkileri` (`cID`, `yLevel`, `yName`) VALUES (%d,%d,'%s')",ceteler[bosid][cID],10,"KURUCU");
mysql_query(mysqlC,str);

format(str,sizeof(str),"SELECT * FROM cete_yetkileri ORDER BY yID DESC LIMIT 1");
mysql_query(mysqlC,str);
cache_get_value_name_int(0,"yID",game_players[playerid][pCeteYetkiID]);

return 1;
}

Buradaki Kullanım Hakkında Yorumunuz Nedir , Tek Sefere Mahsus Bir Kaç Sorgu Atılıyor Bunlar Değişkenlere Atılıyor Ve Bu Değişkenler Üzerinden Kontrol Ediliyor , En Son Oyuncu Cıkarken Oyuncu Verileri Kaydediliyor Cache_delete şuan Kullanmadım Onuda Ekleyeceğim

telefonayım baktım attığın koda, sistem genel olarak mantıklı ilerliyor, tek seferlik sorgularla veri alıp değişkenlere atamak sade ve işlevsel bir yöntem olmuş.

Ancak bazı noktalarda küçük geliştirmeler yapabilirsin

Yeni oluşturulan çetenin id sini almak için tekrar SELECT sorgusu atmak yerine mysql_insert_id() fonksiyonunu kullanabilirsin, bu hem daha performanslı hem de daha doğru bir yöntemdir.

Yaptığın SELECT sorgularından sonra cache_delete kullanmaman uzun vadede bellek tüketimini artırabilir. Özellikle slot sayısı yüksek sunucularda bu durum FPS düşüşü ve veri güncellemelerinde gecikmeye neden olabilir.

Sorgulardan sonra hata kontrolü yapmaman olası bir SQL hatasını fark etmeyi zorlaştırır. mysql_errno() gibi fonksiyonlarla hataları yakalayıp loglaman daha güvenli bir sistem sağlar.

Tekrar eden SQL bloklarını fonksiyonlaştırarak kodun okunabilirliğini ve sürdürülebilirliğini artırabilirsin.

Genel olarak temel yapı doğru, sadece ufak dokunuşlarla daha temiz, performanslı ve hataya dayanıklı bir sistem elde edebilirsin.

mysql_insert_id() Böyle Bir Kod oldugunu bilmiyordum deleteler konusunda farkındayım deneme için yazıyorum. mysql_insert_id() Nasıl Kullanılıyor ?

[Krips Je]

mysql_insert_id() Böyle Bir Kod oldugunu bilmiyordum deleteler konusunda farkındayım deneme için yazıyorum. mysql_insert_id() Nasıl Kullanılıyor ?

dostum mysql_insert_id() fonksiyonu veritabanına son eklenen kaydın otomatik artan (AUTO_INCREMENT) id sini döndürür. Yani INSERT INTO ile veri ekledikten hemen sonra bu fonksiyonu çağırarak o verinin id sine ulaşabilirsin.

Sende çete kurma işleminden sonra son çetenin idsini almak için SELECT * FROM ceteler ORDER BY ceteID DESC LIMIT 1 gibi ekstra bir sorgu atmak yerine

PAWN Kodu: Seç

mysql_query(mysqlC, str, false);
new lastID = mysql_insert_id();
ceteler[bosid][cID] = lastID;

Bu şekilde hem fazladan bir select sorgusu atmamış olursun, hem de doğrudan doğru veriyi alırsın. Performans açısından da fark yaratır çünkü gereksiz sorgular azalır.

cache_delete konusunu da test edip sisteme entegre etmen iyi olur. Select sorgularından sonra cache belleği temizlemezsen, zamanla RAM kullanımı artabilir. Özellikle yoğun sunucularda bunun etkisi daha net görülür.