Ses derniers messages sur les forums
Je dirais que c'est une question de préférence.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Qu'est-ce qui t'empêche de faire un map ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Non, ce n'est pas facile. Sinon ça se ferait en PHP (oui, je trolle :p ).
Tu trouveras les concepts du multi-thread et du daemon assez facilement en cherchant le web.
Par processus permanent, je parlais d'un processus qui n'est pas invoqué à la demande, mais qui est tapis dans l'ombre prêt à dévorer tes visiteurs :D
C'est un concept à opposer au fonctionnement du serveur Web. Lorsque une requête HTTP atteint ton serveur Web, ce dernier se dublique. Le processus original continue d'écouter le réseau, tandis que le processus fils va déterminer ce qu'il doit renvoyer comme réponse au client Web. S'il trouve le fichier, il le sert et disparaît. Dans le cas d'un script PHP, il va faire traiter le fichier PHP par le module PHP pour Apache par exemple. PHP aura un contexte d'exécution qui disparaîtra avec le fils qui mourra après avoir envoyé les données traîtées au client.
Comme tu peux le comprendre, toutes ces invocations sont éphémères, le contexte est perdu à chaque fin de script. C'est pour ça qu'on a besoin d'une base de données, des sessions, etc pour conserver des données entre deux requêtes HTTP.
C'est ainsi que fonctionne le Web.
Mais lorsque tu as besoin de gérer un univers persistant, ce fonctionnement peut être handicapant pour conserver la cohérence du monde. C'est pourquoi on peut imaginer un daemon qui parle avec son propre protocole, qui garanti l'atomicité des accès, la validité des actions, etc. Libre au concepteur d'utiliser une base de données comme solution de stockage des données. Le point important du daemon, c'est que tu peux lui faire gérer des timers et donc déclencher des événements telle que la pousse progressive des arbres et compiler les données en temps réel.
Bref, tout dépend de ce que tu exiges comme fiabilité des informations générées par ton application.
Très honnêtement, essaye-toi à un premier jeu en PHP/MySQL qui gère les ressources toutes les 10 ou 20 requêtes. Ce sera un bon début.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
C'est joliment écrit. Juste quelques points :
les jours ne durent pas 24 × 3600 secondes. En fait tu risques d'avoir des bogues étranges en gérant manuellement les dates.
Ensuite, on peut regretter le choix de l'héritage de la classe date par la classe calendrier. C'est sémantiquement impropre car un calendrier n'est pas une date, mais une agrégation de dates.
Autre détail, qui concerne tes regex. Pourquoi utilises-tu la notation POSIX plutôt que la PCRE ?
Et pour finir, c'est dommage que tu n'utilises pas la notation phpdoc pour les commentaires de fonction.
Mais globalement c'est bien.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
C'est possible qu'ils n'utilisent pas une base de données en direct. L'idée ce serait d'avoir un processus permanent qui fournit les données métier, en gérant le monde persistant.
Et le processus permanent tu peux le faire en PHP... mais ce serait mieux de le faire avec un langage qui fournit le multi-thread (sinon le daemon risquerait de manquer de réactivité.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Essaye de faire précéder l'insertion par une suppression :
delete from visiteurs_online where ip ='127.0.0.1' ;
Et dis-moi si le problème de clé survient à nouveau.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
C'est peut-être un peu compliquer à mettre en place, quand on débute.
L'idée c'est de stocker les résultats de la requête dans un tableau, puis de réserver le résultat dans une zone mémoire persistante. Ainsi, à la prochaine invocation de la requête, le script aura simplement besoin de regarder la zone mémoire et produire le résultat.
Il y a plusieurs outils qui permettent de faire ça. En particulier les sessions. Mais attention à ne pas surcharger la session. Une recherche qui retourne un résultats de plusieurs dizaines de Mo risque de mettre à genoux le serveur dans certaines configurations. C'est pourquoi La Globule parlait de memcache, qui permet, entre autre choses, de conserver les sessions en mémoire vive.
Mais bon, une pagination avec des limit est suffisant pour commencer et faire quelque chose qui marche.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Quel est le create de la table ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Tu ne peux pas faire ça, donc il va falloir faire le sioux.
Par exemple, insérer ton bâtiment dans la table dès que tu le mets en construction, et sauver l'état dans lequel il est créé (en construction par exemple).
Comme ça, l'achèvement de la maison sera déterminée par les requêtes qui consulteront l'état de la maison.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(claires38) Au delà du fait que tu réponde à un sujet vieux d'un an, tu aurais pu constater que des solutions furent apportées. D'ailleurs, j'espère que tu ne plante pas ton code dans le form[@onsubmit] :D
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.