Crontab

[Sôbi]

newPoints te donne les points à l'instant de la query, donc ce n'est pas la donnée à mettre à jour (même s'il se peut que MySQL sache "rétro-pédaler" et convertir ce UPDATE en un UPDATE de la table sous-jascente, mais je ne parierai pas trop dessus, surtout que la date n'a pas été mise à jour elle).

UPDATE `joueur` SET `oldPoints`=`newPoints` - 1, `datePoints`=NOW() WHERE joueur.id =1

C'est là où je doute de la dénomination "oldPoints" (mieux vaudrait dire "pointsADateT" et remplacer datePoints par "dateT")

D'ailleurs, la mise à jour du datePoints pourrait peut-être même se faire en TRIGGER (à voir). Dans l'idée, le TRIGGER se déclanche quand le champ "pointsADateT" est mise à jour, et ce trigger va mettre la date courante (NOW()) dans le champ "dateT".

---

Voilà le détail du système dans un article dédié

Wow ! Merci beaucoup pour ces explications !
Vachement intéressant, je vais tester et voir tout cela des que possible
En tout cas encore un grand merci !

P.S / H.S : Dites-donc, je t'en fait faire des articles à ton blog ah ah ! :p * joke *

H.S 2 : Très bonne explication également dans le lien

H.S 3 : Si je puis me permettre :$ points=currentPoints - 4 <=> points = 30 - 4 <=> points = 26 (a) et non 27 :p

[Polou]

Les vues sont disponibles tout le temps une fois qu'elles sont crées ?
Ou bien ça se réinitialise à chaque connexion ?

[Xenos]

@Sobi
points=currentPoints - 4 <=> points = 30 - 4 <=> points = 26 (a) et non 27 :p
Si, car le temps de taper mes queries, quelques secondes/minutes se sont écoulées, d'où l'écart
J'ai rajouté une note de bas d'article pour éclaircir ce point (je la trouve un peu verbeuse cette note, mais j'ai pas trouvé de meilleure formulation)

@Polou
J'ai du mal à comprendre ta question. Une vue est crée une fois pour toute dans le SQL (jusqu'à ce que tu la supprimes explicitement, comme une table). Tu n'as pas à refaire le "CREATE VIEW" à chaque connexion du coup (je crois qu'il n'existe pas de notion de "TEMPORARY VIEW", à l'image des "TEMPORARY TABLE" qui sont détruites à la fin de la session de connexion). Donc, une fois la vue crée, c'est comme pour une TABLE: tu peux l'utiliser sans devoir la re-déclarer.

[Polou]

C'est bien ça que je demandais
Du coup c'est quoi l'avantage d'une VUE par rapport à une TABLE ?
Excuse-moi hein, je dois surement pouvoir trouver ça sur la doc MySQL ^^

[rachids]

Salut,

Je dis peut être une bêtise car je suis moi aussi néophyte dans le domaine dès que c'est un peu plus poussé que de simples requêtes SQL.

Je pense que l'intérêt de la vue réside dans le fait que SQL opère des calculs pour les champs et que ces calculs n'auront pas besoin d'être fait ni en PHP (ou Ruby, etc..) ni dans les requêtes SQL de SELECT.

Du coup les SELECT sont très simples et si on veut modifier un truc on a juste à toucher à la vue, les données et les SELECT restent les mêmes.

[Xenos]

Ouep, c'est le premier avantage Salty (qui devient magique quand on a plusieurs clients utilisant la même BDD). C'est un avantage qu'on retrouve dans les procédures stockées également (qui permettent de faire plus qu'un simple SELECT: une vue ne fera jamais qu'un seul SELECT alors qu'une procédure peut faire un ou plusieurs INSERT/UPDATE/DELETE/CREATE/SELECT).

L'autre atout est d'avoir des colonnes calculées tout en ayant une BDD normalisée: si une colonne est calculable à partir des données d'une autre (genre l'exemple de ce topic), alors la vue te permet de le faire sans dénormaliser la BDD alors qu'une table créerait une colonne redondante qui ne serait jamais à jour. D'ailleurs, la vue étant calculée à la volée, cela économise la place de ces colonnes calculées sur le disque (là, on retrouve l'avantage des colonnes virtuelles du MySQL 5.7).

La vue pourrait aussi masquer la complexité d'un stockage. Par exemple, on pourrait stocker toutes les positions des objets du jeu dans une seule table (id, x, y) et utiliser une clef étrangère dans les différentes tables du jeu (la table "arme" possède une colonne idPosition, la table "case" aussi, etc). La vue se chargerait de la jointure automatique. Cela permet de ne pas se taper la jointure à la main (parce qu'on aura besoin de l'info de position dans 90% des cas). La vue peut même masquer cette jointure (au lieu d'avoir arme::nom|idPosition+position::x|y|y la vue renverrait vueArme::nom|x|y|z masquant ainsi le fait que ces données sont stockées sur deux tables).