Trigger ou pas?

[tghpow]

Bonsoir a tous

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?

[niahoo]

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

[Maks]

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 -.-

[Myrina]

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.

[Sephi-Chan]

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.

[Akira777]

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.

[tghpow]

Merci a tous de vos réponses

@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 tard

[Myrina]

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 tard

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