Mensajes

Parece que le faltan las comillas en el valor del where.

WHERE x='afasdf'/WHERE x LIKE '%adfadf%'

¿y si lo haces así?

SELECT MIN(id) FROM users

En teoría, y no es que yo sea un experto en bases de datos, me debería devolver el usuario con el identificador mas bajo.

MOD:

También lo podrías hacer de otra forma:

SELECT * FROM users ORDER BY id ASC LIMIT 1

Hola,

No dices que base de datos estas usando por lo que voy a presuponer que estas usando Mysql. Esta página tiene un listado de las funciones de mysql. No es tan completa en información como la documentación oficial pero esta bastante bien para una búsqueda rápida de funciones.

http://mysql.conclase.net/curso/index.php?tab=Funciones

Lo que estás buscando puede que sea esto:

http://mysql.conclase.net/curso/index.php?fun=MIN

Te devolverán el valor máximo o mínimo de un campo.

Un saludo,

SaXo

Espero que nos invites a jugar cuando lo tengas terminado .

Yo aún sigo pensando en un sistema sin necesidad de usar cron y se me ocurrió la "brillante" idea (o cagada. Vete tu a saber) de crear un servidor para gestión de colas al que le llegen las peticiones y pueda realizar las actualizaciones en tiempo real (con un retardo mínimo) y poder mantener la integridad de datos en la bbdd.

Por ahora esta en pañales y le dedico poco tiempo pero creo que, aunque no se pueda usar para juegos online, se le puede encontrar alguna utilidad.

Si os apetece ver de que estoy hablando, en la documentación de php viene un ejemplo de un cliente-servidor en el que me estoy basando para construir mi aplicación. http://es2.php.net/manual/es/sockets.examples.php

Un saludo,

SaXo

Pues le ando dando vueltas a lo que quieres hacer y aún hay algo que no me cuadra.

Cuando hago una solicitud de actualización al cargar la página, no sólo necesito que se actualicen mis movimientos, si no los del resto de los jugadores. Por lo tanto tendría que comprobar todas las tareas pendientes de ejecutarse en la pool he ir acutalizándolas si procede (fíjate, aún sin necesidad de actualizar los movimientos tendría que comprobarlos todos en cada actualización de la página). Aparte de ser un consumo considerable de procesos en el servidor ¿No aparecería un problema de sincronismo de datos con el tiempo? 

Puede que la solución más razonable pase por una combinación de ambas formas.

Un saludo,

SaXo

Hola ,

Vamos a analizarlo con un ejemplo más pequeño.

Estamos jugando tu y yo una partida de ajedrez. El movimiento de una pieza tarda 1 minuto por cada casilla que tenga que desplazarse. Ninguno de los dos sabemos que movimiento hizo el contrario hasta que no se complete el tiempo de movimiento de la pieza.

Por lo tanto ambos tenemos que actualizar cada cierto tiempo el tablero para ver si se ha completado el movimiento. Suponiendo que como máximo puedo hacer 50 peticiones por minuto de actualización al tablero para ver los movimientos estaríamos haciendo entre los dos 100 peticiones máximo a la base de datos para comprobar si se ha completado el movimiento (comprobación y actualización en caso de que proceda).

Si dispongo de un script que me actualiza los datos independientemente de las solicitudes de actualización de la página, sólo realizare una petición cada x tiempo (probablemente el tiempo mínimo de movimiento de una pieza. 1 minuto por casilla) y una única actualización en la base de datos cuando se termine el movimiento de la pieza (o piezas que cumplan el tiempo en la actualización).

Claro que el uso de AJAX no es un adorno. Yo lo usaría para ver el tiempo que queda para finalizar el movimiento de la pieza, actualizar el tablero y en cualquier caso se podría usar para mandar un flag de actualización.

Como he dicho antes, se pueden hacer de varias formas. La forma que me parece más acertada es la de tener una pieza que me haga las actualizaciones de forma independiente a la web, incluso se puede montar un emulador de threads con curl para mejorar el rendimiento. De esta forma no necesito que ningún usuario este conectado a la web para realizar la actualización de los movimientos.

Todo es discutible y no existen mejores o peores formas de implementar algo.

Un saludo,

SaXo

Hola,

Le veo un problema a tu solución. Ya que los datos no son para uso exclusivo del usuario, si no de todos los usuarios que participan en el juego y es prohibitivo realizar una actualización cada vez que un usuario solicite una pagina. Si por ejemplo tenemos 10.000 usuarios que han realizado 20 actualizaciones de datos (construir, aumentar, movimiento, etc..) cada uno... multiplica esos usuarios por las actualizaciones de cada uno y por los accesos que tiene la pagina (pues con unos 10000 usuarios podría llegar perfectamente a los 100.000 accesos diarios) y sin cache, ya que cada acceso realizaría una comprobación de las tareas y una actualización en la base de datos.

Lo más sensato sería realizar una pool de actualizaciones y un sistema de actualización. No tiene por que ser con cron ya que podríamos lanzar un cgi en el servidor que este constantemente comprobando y ordenando las tareas de la pool y actualizando los datos cuando sea necesario (con un uso de cache en memoria se aumentaría el rendimiento). Minimizando al máximo los accesos de escritura a la base de datos por parte de los usuarios (sólo escribirían en el caso de completar una acción y no siempre que cargue una página al realizar una actualización masiva de acciones).

Probablemente existan otras formas de hacer esto, pero a mi no se me ocurre ninguna buena que no sea usar un aplicativo aparte de la aplicación web para ir actualizando los datos de forma masiva sin perjudicar al rendimiento de la aplicación web.

Sobre el uso de Ajax para hacer esto se podría discutir... pero al ser javascript sería necesario que el usuario estuviera conectado para poder realizar las actualizaciones.

Un saludo,

SaXo

Hola,

Bueno, definir la forma correcta de manejar datos en un fichero  depende bastante de cómo pueda usar el fichero ese usuario. Si por ejemplo tuviera un formulario donde el usuario introduce una serie de configuraciones para almacenarlas en un fichero optaría por usar datos serializados para almacenarlos (independientemente si va a un fichero o a base de datos). Si por ejemplo es el usuario el que confecciona el fichero para aplicar una configuración optaría por definir un patrón sencillo para evitar todos los errores que puedan derivarse. La elección de usar llaves para montar la estructura es más que probable que se produzcan muchos errores por que se olvidado de una llave o la estructura no es la correcta.

Así, a bote pronto, usaría una estructura parecida a esta. Aunque luego puede sufrir alguna variación dependiendo de las necesidades.

field_1 : a,b,c,d,e,f
field_2 : d
field_3 : versión 1

Ahora, existen varias formas de leer un fichero y obtener los datos de para formar las estructuras de datos adecuadas.

Voy a probar la forma en la que la suelo hacer ya que siempre me ha dado un buen resultado a la hora de manejar este tipo de ficheros.

$f = fopen('configure.cnf','r');
while ($value = fscanf($f,"%s : %s\n")) {
  list($clave,$valor) = $value;
  $arr[$clave] = explode(',',$valor);
}
fclose($f);

Existen otras formas de hacer esto, que no son ni mejores ni peores, y dependerán de las necesidades que tengamos en el momento para decidir usar una u otra forma.


Un saludo,

SaXo

Hola,

Por lo que he visto en los proyectos en los que he colaborado, se suelen usar todas las formas . Normalmente se maneja la variable en una sesión o variable global para que este disponible en todo el ámbito de la aplicación.Es un recurso más que esté en la url, se puede usar para establecer el idioma de la sesión o para ser manejada con mod_rewrite.

Sobre las cookies... Hablemos de casos concretos por que es un recurso más y dependiendo del caso sería bueno usarlas o no  . Personalmente prefiero no usarlas y menos para guardar ids de sesiones. Pero en algunos casos su utilidad es discutible.

Un saludo,

SaXo

Si y no a todo lo dicho.

Es parcialmente correcto.

cuando hacemos un header, lo que estamos haciendo es modificar la cabecera que se ha enviado al cliente. El error se produce cuando se impreso algo por pantalla, como un echo, printf, un error, etc... ya que después de enviar la información al cliente no se puede modificar la cabecera produciendo un error del tipo que comentan más arriba.

ob es el buffer de salida php. Cuando usamos un ob_start lo que estamos haciendo es el uso del buffer salida de php para que el código que se esta ejecutando realize la ejecución en el buffer y una vez terminada obtener la ejecución del buffer y liberarlo. De esta forma, como aún no se enviado información al cliente se puede modificar la cabecera sin problemas después de un echo o un printf.

Un saludo,

SaXo