JeuWeb - Crée ton jeu par navigateur
Trigger ou pas? - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Trigger ou pas? (/showthread.php?tid=6491)



Trigger ou pas? - tghpow - 11-11-2012

Bonsoir a tousSmile

Toujours en train d'en apprendre plus en cours, je cesse de remettre en doute mon code actuel (Passage a la POO recemment par exemple^^).

Cette fois ci, cela concerne les triggers. Je me demande si je doit les utiliser ou pas.
Pour vous donner un exemple:

J'ai fait une fonction UpBatimentVillage (qui monte un batiment produisant une ressource indiqué en paramètre) , elle fait ceci:

1)Diminue les ressources totales du joueur car il doit payer ce up de level.
2)Augmente le niveau du Batiment
3)Augmente la production du joueur

Sur ces 3 actions, la derniere pourrait être un trigger (si j'ai bien compris mon cours^^).
Jusqu'a présent, c'est une requête SQL dans la fonction UpBatimentVillage..devrais-je passer ca en trigger?

Si oui pourquoi? Un prof ma dit ceci par mail:
"L'idée du trigger est surtout de factoriser ce comportement "sur la
table" afin de ne pas avoir à le dupliquer x fois sur les programmes
appelants.
C'est aussi plus lisible au niveua de la base de données car on voit le
lien entre des colonnes de différentes tables.
La notion d'optimisation du traitement se voit surtout dans les
procédures stockées (prochain cours de BD).
Cdt"


J'imagine être d'accord avec lui x) Mais vous, qu'en pensez vous?


RE: Trigger ou pas? - niahoo - 11-11-2012

Comment est calculée la production d'un joueur ?


RE: Trigger ou pas? - Maks - 11-11-2012

J'aime pas trop les trigger perso... Je préfère séparer les rôles. La BDD c'est pour stocker des données. Sinon après y'en a partout -.-


RE: Trigger ou pas? - Myrina - 11-11-2012

Le trigger a beaucoup d'avantages:
- c'est le moteur de BDD qui travaille et non Php d'où gain de performance,
- il n'y a aucun risque d'oubli du traitement; c'est le moteur de la BDD qui s'occupe de l'invoquer avec les arguments adéquats
- il est englobé dans la transaction automatiquement donc aucun souci de gestion du rollback

Mais il y un énorme inconvénient: dans le cas d'une gestion des données via cache, le cache n'est pas au courant des actions faites par le trigger; au moins cela nécessite un rechargement des données, au pire l'action du trigger peut être écraser lors de la sauvegarde effective du cache en BDD.


RE: Trigger ou pas? - Sephi-Chan - 11-11-2012

Je n'aime pas les triggers au niveau de la base de données car elle implique une séparation de la logique métier (dans le mauvais sens du terme). Je préfère encapsuler mes interactions dans mes classes métiers.

Par exemple, dans Conquest on Rails j'ai des classes qui encapsulent mes interactions (voir les tests unitaires associés pour l'utilisation).

Je préfère avoir mes classes qui interagissent entre elles. Par exemple :


class Player
def upgrade_building(building)
Player.transaction do
if self.can_afford?(building.upgrade_costs)
self.debit_resources(building.upgrade_costs)
building.upgrade
else
raise NotEnoughResources
end
end
end


def can_afford?(costs)
# Contrôle si le joueur dispose des ressources.
end


def debit_resources(cost)
# Retranche les ressources des réserves du joueur.
end
end


class Building
def upgrade
# Augmente le niveau du bâtiment.
end
end

En plus, on peut même facilement effectuer certaines opérations en tâche de fond (via un système de queueing) si on veut réduire la charge du serveur Web. Et on garde notre logique applicative dans un seul langage, pour plus de cohérence et de facilité de maintenance.


RE: Trigger ou pas? - Akira777 - 11-11-2012

Idem que Sephi-chan et Maks, je préfère aussi garder ma logique métier dans un même langage, ca facilite la maintenance et le changement de SGBD.

Pour tes triggers, je pense à plusieurs solutions de remplacement :

- mettre en place un système de threading PHP : exemple ici

Là, j'arrive pas à me sortir de la tête que ce système est sale, je pense que c'est psychologique surtout...

- mettre en place dans ta logique de code un système d'Events, bon je te l'avoue faut bien être rodé niveau code et avoir pensé ça dès le début du projet. article en anglais ici

Cas concret : j'ai un blog qui n'indexe pas le contenu des billets en base de donnée (tout est stocké en blob). Imaginons un module Blog caractérisé par une classe Blog.
Mais je voudrais bien pouvoir faire des recherches sur ce contenu, dès lors, j'ai un module Blog_Search caractérisé par une classe Blog_Search.
Mon module Blog a 3 events : blog_post_create, blog_post_update, blog_post_delete.
Mon module Blog_Search écoute ces 3 évenements, et va mettre à jour son fichier d'index en utilisant les données du module Blog, fichier qui sera plus tard utilisé quand des recherches seront effectués sur le blog.


RE: Trigger ou pas? - tghpow - 11-11-2012

Merci a tous de vos réponsesSmile

@niahoo, la production d'un joueur dépend tout simplement du niveau de son Bâtiment produisant la ressources.
J'ai une table dans la BDD, qui as deux champs: Le niveau, et la production associé.

Je pense faire comme sephi (ce que je pensais déjà faire plus ou moins), c'est a dire laisser les classes interagirent entre elle. Donc finalement, je ne vais pas vraiment changer le code actuel.

Akira, j'ai lu ton article sur les Events, j'avoue que ça m’intéresse pas mal..Je le garde sous la main pour plus tardSmile


RE: Trigger ou pas? - Myrina - 11-11-2012

(11-11-2012, 07:36 PM)tghpow a écrit : Akira, j'ai lu ton article sur les Events, j'avoue que ça m’intéresse pas mal..Je le garde sous la main pour plus tardSmile
De toute façon, c'est ce qui correspond au mieux au fonctionnement des triggers.

Code :
begin transaction
fire pre-(update/insert/delete) events
update/insert/delete occurence
fire post-(update/insert/delete) events
commit