[steki.]

Quote:

Originally Posted by Joao Pedro Ainda com uma boa estrutura eu nгo acho uma boa. Por que pense, para vocк pegar os dados de um SELECT, vocк terб que usar o mysql_function_query e ainda criar uma callback para aonde esses dados serгo enviados. Entгo em questгo de linhas, seria muito maior...

Nгo estou me referindo a linhas.

Quote:

Originally Posted by [JD]BlackFire eu, como administrador de servidores sa-mp e mysql, acredito que para sa-mp nгo й a melhor alternativa, atй mesmo pelos plugins terem um delay e funcionalidades reduzidas, jб o servidor mysql a performance dele vai depender dos recursos da mбquina. A melhor alternativa em minha opiniгo й SQLite, que o prуprio server sa-mp dб suporte.

O ъnico delay significativo seria a espera "hang", se uma query estб na fila para ser chamada pelo abstrador.

Quote:

Originally Posted by rjjj Pelo que entendi, seu objetivo й usar variбveis que nгo sгo removidas da memуria atй o fechamento do samp-server como buffers para resultados de queries ao banco de dados . Pawn й single-threaded. Uma instruзгo da mбquina abstrata й completamente processada para que a leitura da prуxima comece. Apesar de manipular vбrias threads, o plugin MySQL do BlueG tem que interagir com a mбquina abstrata com uma thread sу . Algumas das instruзхes que citei servem para executar funзхes nativas. Somente quando estas sгo totalmente lidas й que passa a ser a vez da instruзгo seguinte. Isso significa que a parte de Pawn й uma sequкncia, evitando, por exemplo, que duas callbacks passem por execuзгo ao mesmo tempo . Sendo assim, tudo ocorrerб bem se as variбveis em questгo forem sempre resetadas no inнcio da callback de obtenзгo de dados. Espero ter ajudado .

Nгo й bem esse o ponto, mas й um fator bem discutнvel.