Une procédure stockée, comme son nom l'indiquée, est stockée sur le serveur MySQL: on la crée une fois, et on peut l'exécuter autant de fois que nécessaire, même après s'être déconnecté puis reconnecté du serveur MySQL (donc, d'une page PHP à l'autre).
Et tu fais mouche pour l'objectif: j'allège mes codes PHP de toutes les boucles et autres traitements de données.
Typiquement, Une classe PHP == Une table en BDD, je trouve que c'est très peu pratique car le code PHP devient un pur reflet du code SQL. En cela, je trouve que cela rend au contraire très dépendant du SGBD, et surtout de sa structure interne. Avec les colonnes virtuelles, et les vues, ça se passe comment?
Être obligé de lire les données du SQL, d'en faire des objets PHP, de traiter ces objets PHP, parfois de les compléter, puis de les renvoyer au SQL pour qu'il les sauve... Même s'il y a plein de frameworks qui font ça, je préfère éviter un tel trafic réseau et dire au SQL "vas-y, je veux ça" (ça rappellera peut-être l'approche "East" débattue il y a un moment ^^).
C'est d'ailleurs un soucis qu'on a au taff: on se retrouve avec des cas où on demande une liste d'objets au SQL, qui nous en retourne par exemple un bon millier, puis on fait des traitements PHP, et enfin, on demande au SQL de compléter ces 1.000 objets avec d'autres infos... Et là, c'est le drame: le serveur SQL ne sait pas répondre à des requêtes type "SELECT ... FROM ... WHERE id IN (...1000 ids...)".
Niveau implémentation, j'ai 1 fichier SQL par procédure, exécuté automatiquement à sa sauvegarde (AutoHotkey) en local, et exécuté automatiquement également lors du déploiement en ligne (Mage ou Magallanes).
Je peux te donner les exemples de code si tu veux? Je n'ai pas trop cherché de doc sur le net relative à mon approche, donc bon, c'est un peu expérimental et si cela se trouve je me plante (l'autre approche d'Akira est probablement plus documentée que la mienne). Si je me plante pas et que j'arrive à tenir un jeu viable comme ça, j'essayerai de présenter cette approche de façon plus formelle.
[Edit]
Pour les mocks, j'allais oublier, même si je n'en ai pas encore fait, je procèderai ainsi:
• Coté PHP, le serveur MySQL est un "serveur-API", donc je peut le mocker soit en créant un faux serveur MySQL (un peu tendu quand même), soit avec un serveur MySQL dont les procédures renvoient toujours les mêmes résultats.
• Coté MySQL (vu que j'y ai de la logique je serai censé pouvoir le tester), je créerai un jeu de données bidon, puis j'exécuterai la procédure SQL et je vérifierai l'impact sur les données de la BDD (le tout dans une base dédiée aux tests). Mais là, je reconnais ne pas connaitre de Framework dédié à ce genre de test. Après, ça se résume à "1 fichier SQL de la procédure + 1 fichier SQL de test qui initialise les données puis appelle la procédure puis vérifie son résultat et renvoie TRUE ou FALSE". Mais il n'y aura pas de code coverage (en tous cas, je ne connais pas d'équivalent "SQLunit" à PHPunit).
Et tu fais mouche pour l'objectif: j'allège mes codes PHP de toutes les boucles et autres traitements de données.
Typiquement, Une classe PHP == Une table en BDD, je trouve que c'est très peu pratique car le code PHP devient un pur reflet du code SQL. En cela, je trouve que cela rend au contraire très dépendant du SGBD, et surtout de sa structure interne. Avec les colonnes virtuelles, et les vues, ça se passe comment?
Être obligé de lire les données du SQL, d'en faire des objets PHP, de traiter ces objets PHP, parfois de les compléter, puis de les renvoyer au SQL pour qu'il les sauve... Même s'il y a plein de frameworks qui font ça, je préfère éviter un tel trafic réseau et dire au SQL "vas-y, je veux ça" (ça rappellera peut-être l'approche "East" débattue il y a un moment ^^).
C'est d'ailleurs un soucis qu'on a au taff: on se retrouve avec des cas où on demande une liste d'objets au SQL, qui nous en retourne par exemple un bon millier, puis on fait des traitements PHP, et enfin, on demande au SQL de compléter ces 1.000 objets avec d'autres infos... Et là, c'est le drame: le serveur SQL ne sait pas répondre à des requêtes type "SELECT ... FROM ... WHERE id IN (...1000 ids...)".
Niveau implémentation, j'ai 1 fichier SQL par procédure, exécuté automatiquement à sa sauvegarde (AutoHotkey) en local, et exécuté automatiquement également lors du déploiement en ligne (Mage ou Magallanes).
Je peux te donner les exemples de code si tu veux? Je n'ai pas trop cherché de doc sur le net relative à mon approche, donc bon, c'est un peu expérimental et si cela se trouve je me plante (l'autre approche d'Akira est probablement plus documentée que la mienne). Si je me plante pas et que j'arrive à tenir un jeu viable comme ça, j'essayerai de présenter cette approche de façon plus formelle.
[Edit]
Pour les mocks, j'allais oublier, même si je n'en ai pas encore fait, je procèderai ainsi:
• Coté PHP, le serveur MySQL est un "serveur-API", donc je peut le mocker soit en créant un faux serveur MySQL (un peu tendu quand même), soit avec un serveur MySQL dont les procédures renvoient toujours les mêmes résultats.
• Coté MySQL (vu que j'y ai de la logique je serai censé pouvoir le tester), je créerai un jeu de données bidon, puis j'exécuterai la procédure SQL et je vérifierai l'impact sur les données de la BDD (le tout dans une base dédiée aux tests). Mais là, je reconnais ne pas connaitre de Framework dédié à ce genre de test. Après, ça se résume à "1 fichier SQL de la procédure + 1 fichier SQL de test qui initialise les données puis appelle la procédure puis vérifie son résultat et renvoie TRUE ou FALSE". Mais il n'y aura pas de code coverage (en tous cas, je ne connais pas d'équivalent "SQLunit" à PHPunit).