Posts: 185
Threads: 14
Joined: Oct 2014
Reputation:
0
igual una consulta a la bd no tarda tanto, a menos que tengas la bd en un host donde tu servidor tenga que dar muchos saltos para llegar.
Posts: 1,198
Threads: 9
Joined: Dec 2010
Reputation:
0
Que motor de tablas estas ocupando? Que intermediario estas ocupando para conectar tu servidor con MySQL?
Posts: 122
Threads: 10
Joined: Mar 2011
Reputation:
0
Yo te recomendaria ejecutar las sentencias cuando se desconecte el jugador. Si bien mysql es un sgbd robusto capas de soportar y reposnder hartas consultas, por un tema de buenas practicas, haslo al momento de desconectar
Posts: 1,198
Threads: 9
Joined: Dec 2010
Reputation:
0
Gabo, cuando el servidor se cierra de golpe, las estadнsticas no se guardan. Por eso algunos actualizan cada ciertos minutos.
Supongo lo sabнas, pero lo recalco para otros. Jaja.
Posts: 122
Threads: 10
Joined: Mar 2011
Reputation:
0
Buen punto ese... alfinal en pawn no se puede aplicar el concepto de buenas practicas para algunas cosas
...en fin, volviendo al tema, si podrias hacerlo ingane al momento de q se ejecute el payday, pero, te aconsejaria evitar tener q enviar las sentencias a nivel de script... me explico, mysql soporta triggers y procedimientos almacenados, por tema de tiempo no puedo explicarte todo sobre eso en detalle, pero en tu caso serian de mucha utilidad y evitarias ejecutar 3 consultas
Los triggers son funciones que se ejecutan antes o despues de realizar una consulta a una tabla, puedes hacer validaciones de datos a nivel de base de datos, claro q ocupas proceso en el motor de base dr datos, pero si tienes buen host no tendrias tantos problemas y los procedimientos almacenados tambien son como funciones pero a diferencia de los triggers, no se ejecutan automaticamente, los tienes que llamar como llamar a una funcion en programacion.
Te recomendaria averiguar un poco de eso si es q te interesa. Saludos
Posts: 1,198
Threads: 9
Joined: Dec 2010
Reputation:
0
Si no vas a hacer eliminaciуn de registros, usa "MyISAM" que es mucho mas rбpido en "UPDATE" e "INSERT".
Con lo de "intermediario", me referнa a plugin. Si usas el de blueG, usas el sistema de multi hilo?
Posts: 221
Threads: 0
Joined: Oct 2010
Reputation:
0
Una consulta a una base de datos es bastante costosa, uses hilos secundarios o lo ejecutes en el principal, hacer eso que planteas es una mala prбctica.
Yo para evitar perder los datos cuando el servidor "crashea", lo que harнa seria almacenar, desde que el jugador se conecta hasta que se desconecta, en un archivo log, las transacciones mas relevantes, como venta o compra de armas, casas, movimientos de dinero, etc... Cuando el jugador salve sus datos en la base de datos al desconectarse, eliminas el archivo. Los accesos/escritura a ficheros son poco costosos y se realizan bastante rбpido.
Si te resulta relativamente complejo interpretar un fichero de log y recuperar la informaciуn dejando la base de datos en un estado no consistente, quizбs deberнas probar alternativas directamente en SQL, como almacenar solo cosas excesivamente importantes, como compras de excesivo costo ... guardar aleatoriamente algъn usuario de nivel mбs alto, o mas bajo si no quieres dar mala imagen.
De todas maneras te aseguro que deberнas evitar las operaciones con la bases de datos, las bases de datos no son para realizar intercambios constantemente, ademбs de eso te recomiendo que revises algъn tema acerca de modelos relacionales para construir tu base de datos, la mayorнa de la gente en esta comunidad cree saber algo de MySQL o bases de datos, y el lenguaje SQL no es mбs que la punta del iceberg de todo un modelo que lleva aсos de estudio, no es muy apropiado para SA-MP la verdad a no ser que almacenes grandes cantidades de datos y te pueda brindar numerosas facilidades el procesar relaciones o eventos automбticos que surjan del tratamiento de los datos.
Lo ideal serнa minimizar los "Crasheos", pero si no puede ser la alternativa del fichero log con las transacciones, que no son mas que acciones del tipo "jug 1 +50$ jug2" y una fecha o algo identificativo, en caso de crashear el server, no se borra, por lo tanto en el proximo inicio podrнas leer todos estos archivos de log y restablecer los datos.
