[steki.]

Bem, depois de alguma revisгo sobre o que eu escrevo nos meus scripts, cheguei а conclusгo que este ponto й razoavelmente discutнvel. Mas do que eu estou falando?
Pra quem confia mesmo em MySQL e sabe que ele dб conta do recado, jб pensou, com hesitaзгo, em escrever um sistema que nгo salve quase nada em variбveis locais.
O truque й bem simples, a integraзгo й bem leve e vocк pode aproveitar a dinamicidade do MySQL com joins, prepared statements, subqueries, etc.

Eu, por mim, jб escrevi alguns sistemas flutuantes, como o sistema de itens, onde as informaзхes sobre os itens e os itens dos players sгo processados em tempo real, sem muita queda de performance, aumentando a 'flexibilidade' do script e tornando-o mais genйrico.
Isto jб existem em muitos jogos MMO e nunca houveram reclamaзхes sobre isso, mas eu queria ouvir a opiniгo da galera que tem uma ligeira manjada de SQL. Tambйm queria convidar as pessoas para fazerem isso. Й bem divertido xD.

:P

[Joao Pedro]

Eu nгo acho uma boa, por que o servidor de gta oscila sua velocidade de conexгo e mesmo se tratando de pedidos localhost, os mesmos podem chegar a demorar segundos. Sem contar que vocк pegando vбrios dados simultaneamente, pois vбrios jogadores poderгo estar pegando esses dados ao usarem seus sistemas, poderia causar um lag no servidor MYSQL, pois todos nуs sabemos que essas pseudo-empresas nгo estгo nada preparadas para grandes armazenamentos de dados.

Para melhor uso do MYSQL, aconselho colocar apenas os dados, digamos mais importantes e os que vocк necessita estar mudando constantemente, assim ficarб mais dinвmicos. Exemplos de dados:
- Contas
- Organizaзхes
- Empregos

Nгo й que o MYSQL nгo dк conta do recado, os fatores sгo como citei a cima: as pseudo-empresas nгo tem estrutura para grande envio e recebimento de dados em seus servidores MYSQL e vocк pegar um dado de uma variбvel que jб estб alocada na memуria tem uma respostas exageradamente menor do que se vocк pegar em MYSQL.

[ipsBruno]

Quote:

Originally Posted by Joao Pedro Eu nгo acho uma boa, por que o servidor de gta oscila sua velocidade de conexгo e mesmo se tratando de pedidos localhost, os mesmos podem chegar a demorar segundos. Sem contar que vocк pegando vбrios dados simultaneamente, pois vбrios jogadores poderгo estar pegando esses dados ao usarem seus sistemas, poderia causar um lag no servidor MYSQL, pois todos nуs sabemos que essas pseudo-empresas nгo estгo nada preparadas para grandes armazenamentos de dados. Para melhor uso do MYSQL, aconselho colocar apenas os dados, digamos mais importantes e os que vocк necessita estar mudando constantemente, assim ficarб mais dinвmicos. Exemplos de dados: - Contas - Organizaзхes - Empregos Nгo й que o MYSQL nгo dк conta do recado, os fatores sгo como citei a cima: as pseudo-empresas nгo tem estrutura para grande envio e recebimento de dados em seus servidores MYSQL e vocк pegar um dado de uma variбvel que jб estб alocada na memуria tem uma respostas exageradamente menor do que se vocк pegar em MYSQL.

Certamente isto й verdade. Mas buscando um bom host ou atй um VPS potente e particular pode-se fazer isto, dizer que nгo й aconselhado devido a estrutura de algumas empresas da SA:MP й generalizar demais, hб tantas alternativas.

[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...

[[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.

[paulor]

Й uma уtima ideia, mais basta saber-mos se й a melhor opзгo..

[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 .

[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.

[ipsBruno]

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 й o ponto. Mas mesmo assim, dб para facilmente fazer um plugin e basea-lo todo em uma thread diferente;