Eh ben oui j'avais pas pensé à la répercussion en chaine. Bon perso moi ça me paraît sympa : facile à coder, pratique parce que ça revient à créer un event "gagnage de thune" lors duquel tu peux déclencher d'autres trucs que refiler un pourcentage à ton boss.
les super requêtes SQL c'est bien pour la performance (vu comment mes 30 requêtes seront simples et basées que sur des ID ça doit rouler à toute vitesse), mais faut s'en faire une pour chaque truc complexe à gérer. Je sais pas faire
As-tu pensé aux arbres par intervalles ? C'est assez sympa pour traiter tout ce qui peut-être classé en arbre, parfait pour les suzerains et les vassaux.
http://sqlpro.developpez.com/cours/arborescence/
Avec ça et en stockant le pourcentage reversé dans la table des seigneurs sur le vassal ça doit simplifier pas mal. Après dans ma tête si tu écris une requête récursive, mysql l'exécutera autant de fois qu'il y a de récursion. Certes tu n'auras pas la perte de vitesse due à l'IPC
Bon alors, avec mes intervalles là, dès qu'un vassal gagne quelques PO, je récup en une seule requête toute la hiérarchie au dessus du mec sans récursion, avec les thunes actuelles de chacun et le pourcentage qu'ils doivent reverser à leur boss. (je crois qu'il faut une racine unique obligatoirement, t'as qu'à mettre Dieu en haut et lui il prend 0%, basta) (sympa le mec !)
Ensuite ben côté code je calcule mes nouvelles valeurs pour savoir combien chacun va gagner, et je me fais un update avec des additions et pas des remplacements : "thune = thune + $gain" au lieu de "thune = $new_thune", comme ça si une autre requête d'un joueur met à jour une partie de suzerains entre le moment ou j'ai fetch leur thune actuelle et celui ou je leur mets leurs gains, ils ne eprdent rien dû à l'update. Le mieux étant encore de mettre ça dans une transaction comme ça t'es sûr que personne n'est floué.
Et si je compte bien ça fait 2 requêtes. J'ai peut être oublié un truc.
pour récupérer tous les suzerains d'un vassal : http://sqlpro.developpez.com/cours/arborescence/#L2.7
leur exemple n'inclut pas le vassal le plus bas, pour l'avoir tu fais ça (mais c'est tellement trivial que tu avais compris)
Non en plus je crois que je dis de la merde, parce que quand un vassal gagne des thunes, il en reverse un certain pourcentage à son suzerain, qui fera pareil et ainsi de suite, mais ces pourcentages s'appliquent sur les gains de chacun et pas leur cagnotte, donc à aucun moment il n'est utile de connaître les thunes actuelles de chaque protagoniste. Donc pas besoin de transaction (sauf si deux updates en même temps sur une ligne mais ça je suppose que sans transaction un SGBDR est pas con au point de télescoper les deux updates -- j'en sais rien)
Ensuites si tu veux faire un buffer qui ne stocke que le montant et qui va ponctionner chaque X jours, quitte à ce que certains ne puissent pas payer, alors ton problème est toujours là puisque il faudra itérer sur chaque type pour voir s'il l'a déjà. Mais bon ça devient vraiment compliqué alors, parce qu'il faudra bien produire une sortie pour informer un joueur qu'un de ses vassaux n'a pas cottisé.
Moi, je ferais plutôt du paiement direct. à l'époque ils n'avaient pas ça mais bon ça simplifie pas mal les choses et au final ça reviendra au même.
les super requêtes SQL c'est bien pour la performance (vu comment mes 30 requêtes seront simples et basées que sur des ID ça doit rouler à toute vitesse), mais faut s'en faire une pour chaque truc complexe à gérer. Je sais pas faire
As-tu pensé aux arbres par intervalles ? C'est assez sympa pour traiter tout ce qui peut-être classé en arbre, parfait pour les suzerains et les vassaux.
http://sqlpro.developpez.com/cours/arborescence/
Avec ça et en stockant le pourcentage reversé dans la table des seigneurs sur le vassal ça doit simplifier pas mal. Après dans ma tête si tu écris une requête récursive, mysql l'exécutera autant de fois qu'il y a de récursion. Certes tu n'auras pas la perte de vitesse due à l'IPC
Bon alors, avec mes intervalles là, dès qu'un vassal gagne quelques PO, je récup en une seule requête toute la hiérarchie au dessus du mec sans récursion, avec les thunes actuelles de chacun et le pourcentage qu'ils doivent reverser à leur boss. (je crois qu'il faut une racine unique obligatoirement, t'as qu'à mettre Dieu en haut et lui il prend 0%, basta) (sympa le mec !)
Ensuite ben côté code je calcule mes nouvelles valeurs pour savoir combien chacun va gagner, et je me fais un update avec des additions et pas des remplacements : "thune = thune + $gain" au lieu de "thune = $new_thune", comme ça si une autre requête d'un joueur met à jour une partie de suzerains entre le moment ou j'ai fetch leur thune actuelle et celui ou je leur mets leurs gains, ils ne eprdent rien dû à l'update. Le mieux étant encore de mettre ça dans une transaction comme ça t'es sûr que personne n'est floué.
Et si je compte bien ça fait 2 requêtes. J'ai peut être oublié un truc.
pour récupérer tous les suzerains d'un vassal : http://sqlpro.developpez.com/cours/arborescence/#L2.7
leur exemple n'inclut pas le vassal le plus bas, pour l'avoir tu fais ça (mais c'est tellement trivial que tu avais compris)
SELECT id, nom, thune, pourcentage_reversé
FROM seigneurs
WHERE NFM_BG <= 29
AND NFM_BD => 34
Non en plus je crois que je dis de la merde, parce que quand un vassal gagne des thunes, il en reverse un certain pourcentage à son suzerain, qui fera pareil et ainsi de suite, mais ces pourcentages s'appliquent sur les gains de chacun et pas leur cagnotte, donc à aucun moment il n'est utile de connaître les thunes actuelles de chaque protagoniste. Donc pas besoin de transaction (sauf si deux updates en même temps sur une ligne mais ça je suppose que sans transaction un SGBDR est pas con au point de télescoper les deux updates -- j'en sais rien)
Ensuites si tu veux faire un buffer qui ne stocke que le montant et qui va ponctionner chaque X jours, quitte à ce que certains ne puissent pas payer, alors ton problème est toujours là puisque il faudra itérer sur chaque type pour voir s'il l'a déjà. Mais bon ça devient vraiment compliqué alors, parce qu'il faudra bien produire une sortie pour informer un joueur qu'un de ses vassaux n'a pas cottisé.
Moi, je ferais plutôt du paiement direct. à l'époque ils n'avaient pas ça mais bon ça simplifie pas mal les choses et au final ça reviendra au même.