Okay, je ne connaissais pas l'anayseur des metadata de MySQLi. Ca te retourne quoi (perso, je dirai "country.name" vs "city.name", mais dans des cas autres qu'un INNER JOIN, genre subquery)?
Mouais, je vais prendre l'exemple d'un personnage qui se déplace sur les cases d'un map de jeu; le serveur reçoit la liste des cases par lesquelles il passe (liste calculée, par exemple, par un A* coté client). Je préfère envoyer chaque case à la BDD, qui l'enregistrera alors et activera le TRIGGER qui va sauver l'historique de déplacement dans une autre table (oui, faut 2 tables séparées, c'est sûr ^^), plutôt que de faire plus de code coté client pour faire ces mêmes traitements. Le SGBD se débrouillera tout seul pour limiter les écritures sur le disque. D'autant que si une case du trajet n'est pas autorisée, la BDD va refuser la suite des enregistrement et le personnage sera donc arrêté "au plus loin" sur ce chemin (plutôt que stoppé au début si c'était fait coté client).
Mais bon, c'est pas forcément une méthode objectivement défendable, c'est surtout dû au fait que je pense que la logique métier des données doit se trouver coté SGBD plutôt que dans le code client (cela devient d'autant plus vrai si on a plusieurs clients pour une même logique de BDD, par exemple un client web, un client lourd java et un client tablette, c'est le cas chez Alstom General Electric).
Il me semble que PDO permet le même genre de système pour l'optimisation mémoire (instanciation des objets à la volée, et le GC de PHP se charge de les supprimer s'ils ne sont plus référencés). Oui, si tu fais un fetchAll, PDO te crée un tableau avec tous les résultats dedans (donc lourd), mais un while (...->fetch()) aura le même effet que ton foreach.
C'est pratique à l'usage, cette structure? Là, okay, c'est assez facile à gérer puisque $query est instanciée à la ligne du dessus, mais si jamais $query vient d'un paramètre de méthode, alors comment savoir le mapping à faire dans le setParams()?
Mouais, je vais prendre l'exemple d'un personnage qui se déplace sur les cases d'un map de jeu; le serveur reçoit la liste des cases par lesquelles il passe (liste calculée, par exemple, par un A* coté client). Je préfère envoyer chaque case à la BDD, qui l'enregistrera alors et activera le TRIGGER qui va sauver l'historique de déplacement dans une autre table (oui, faut 2 tables séparées, c'est sûr ^^), plutôt que de faire plus de code coté client pour faire ces mêmes traitements. Le SGBD se débrouillera tout seul pour limiter les écritures sur le disque. D'autant que si une case du trajet n'est pas autorisée, la BDD va refuser la suite des enregistrement et le personnage sera donc arrêté "au plus loin" sur ce chemin (plutôt que stoppé au début si c'était fait coté client).
Mais bon, c'est pas forcément une méthode objectivement défendable, c'est surtout dû au fait que je pense que la logique métier des données doit se trouver coté SGBD plutôt que dans le code client (cela devient d'autant plus vrai si on a plusieurs clients pour une même logique de BDD, par exemple un client web, un client lourd java et un client tablette, c'est le cas chez Alstom General Electric).
Il me semble que PDO permet le même genre de système pour l'optimisation mémoire (instanciation des objets à la volée, et le GC de PHP se charge de les supprimer s'ils ne sont plus référencés). Oui, si tu fais un fetchAll, PDO te crée un tableau avec tous les résultats dedans (donc lourd), mais un while (...->fetch()) aura le même effet que ton foreach.
$query = $this->getQuery('SELECT id, name FROM user WHERE name = :name');
$query->setParams(['name' => 'Sylvain']);
C'est pratique à l'usage, cette structure? Là, okay, c'est assez facile à gérer puisque $query est instanciée à la ligne du dessus, mais si jamais $query vient d'un paramètre de méthode, alors comment savoir le mapping à faire dans le setParams()?