merci pour vos réponses
pour la table in, ce n'est pas pertinent pour les cas auxquels je pense
en effet, l'objectif de mes requêtes avec "in" est d'éviter de charger unitairement plusieurs instances d'une même classe (personnage, item d'inventaire, etc...)
or j'ai besoin pour toute interaction (personnage-personnage, personnage-équipement, personnage-environnement) de ce "in"
ce que je développe est justement basé sur les interactions, du coup quasiment tous les échanges clients serveurs se baseront sur des requêtes de type "in", ce qui rend la mise à jour de table temporaire à mon sens beaucoup trop lourde (performance, synchronisation, concurrence d'accès)
je pense que la table temporaire à son utilité, dans le cas où sa fréquence d'utilisation est assez faible
En fait je me posais aussi la question de requête préparée versus requête directe.
disons que je construis mon système ainsi :
couche DAO (aujourd'hui mes propres classes, demain PDO probablement)
couche Factory
couche Objet Métier
je ne suis pas sûr d'utiliser correctement le terme couche, mais osef en fait ^^
globalement ma couche Factory aurait
des classes spécifiques (liste de personnages, liste d'item, etc...) dont le rôle sera
- de définir la requête qui va bien pour obtenir les données
- de sélectionner pour un enregistrement donné (via son type etc...) la classe qui le portera
- de créer l'instance qui va bien en fonction des données rappatriées
une classe mère générique (abstraite) avec pour fonction
- d'appeler la couche DAO pour lire les enregistrements (et probablement les modifier/créer)
- de récuperer les enregistrements et d'appeler la méthode (abstraite) de création d'instance (cf la classe spécifique)
et puis diverses autres choses, mais ça donne l'idée
tout ça aujourd'hui marche très bien avec ma couche dao personnelle (bon un peu prise du net y a 7 ans mais que je bidouille de temps en temps) mais comme pdo va devenir le standard de php, je préfère reprendre cette partie et exploiter ses possibilités.
normalement pas besoin de requête préparée car je ne charge qu'une fois les données (c'est l'objectif de mes couches : ne faire qu'une requête) mais dans une idée un peu plus générique, j'avais pensé " et si à un moment ou un autre, j ai besoin de récupérer une seconde liste d'enregistrement (voire une troisième, etc..)" et c'était là que me semblait pertinent les requêtes préparées avec le "in"
J'y vois un intérêt réel pour les update/insert d'objet (car là je ne pourrais la plupart du temps ne faire que des requêtes ne touchant qu'un enregistrement) et un intérêt plus théorique pour le "in"
mais bon justement si ça n'existe pas avec le in, pas la peine de creuser plus loin ^^
merci
pour la table in, ce n'est pas pertinent pour les cas auxquels je pense
en effet, l'objectif de mes requêtes avec "in" est d'éviter de charger unitairement plusieurs instances d'une même classe (personnage, item d'inventaire, etc...)
or j'ai besoin pour toute interaction (personnage-personnage, personnage-équipement, personnage-environnement) de ce "in"
ce que je développe est justement basé sur les interactions, du coup quasiment tous les échanges clients serveurs se baseront sur des requêtes de type "in", ce qui rend la mise à jour de table temporaire à mon sens beaucoup trop lourde (performance, synchronisation, concurrence d'accès)
je pense que la table temporaire à son utilité, dans le cas où sa fréquence d'utilisation est assez faible
En fait je me posais aussi la question de requête préparée versus requête directe.
disons que je construis mon système ainsi :
couche DAO (aujourd'hui mes propres classes, demain PDO probablement)
couche Factory
couche Objet Métier
je ne suis pas sûr d'utiliser correctement le terme couche, mais osef en fait ^^
globalement ma couche Factory aurait
des classes spécifiques (liste de personnages, liste d'item, etc...) dont le rôle sera
- de définir la requête qui va bien pour obtenir les données
- de sélectionner pour un enregistrement donné (via son type etc...) la classe qui le portera
- de créer l'instance qui va bien en fonction des données rappatriées
une classe mère générique (abstraite) avec pour fonction
- d'appeler la couche DAO pour lire les enregistrements (et probablement les modifier/créer)
- de récuperer les enregistrements et d'appeler la méthode (abstraite) de création d'instance (cf la classe spécifique)
et puis diverses autres choses, mais ça donne l'idée
tout ça aujourd'hui marche très bien avec ma couche dao personnelle (bon un peu prise du net y a 7 ans mais que je bidouille de temps en temps) mais comme pdo va devenir le standard de php, je préfère reprendre cette partie et exploiter ses possibilités.
normalement pas besoin de requête préparée car je ne charge qu'une fois les données (c'est l'objectif de mes couches : ne faire qu'une requête) mais dans une idée un peu plus générique, j'avais pensé " et si à un moment ou un autre, j ai besoin de récupérer une seconde liste d'enregistrement (voire une troisième, etc..)" et c'était là que me semblait pertinent les requêtes préparées avec le "in"
J'y vois un intérêt réel pour les update/insert d'objet (car là je ne pourrais la plupart du temps ne faire que des requêtes ne touchant qu'un enregistrement) et un intérêt plus théorique pour le "in"
mais bon justement si ça n'existe pas avec le in, pas la peine de creuser plus loin ^^
merci