Pmo découvre à chaque execution le schéma des tables qu'on passe au controller. Cela représente un temps d'exécution infime du fait du caching et des perfs des SGBD. Bien entendu, une fois que le controller t'as crée les objets, tu n'as plus besoin d'intérroger le SGBD ! Tu travailles directement sur tes objets jusqu'au moment du commit();
Ce temps de découverte du schéma de la table via un DESC est beaucoup plus infime que s'il avait à accéder à un fichier xml en lecture ecriture + parsing comme les autres ORM.
Au niveau des 10 000 lignes cela ne change rien, ta table peut également stocker 1 000 000 d'enregistrements.
C'est l'optimisation de ta requête SQL qui est importante, et ça il n'y a que toi qui peut le faire.
PMO est une couche d'abstraction objet c'est aussi de la plomberie, c'est sur que ça n'est pas aussi bien que si c'était un module PHP à part entière car il utilise d'autres couches d'abstraction en dessous .
[^] # Re: Mmmm, voyons voir...
Posté par Code34 . En réponse au journal PMO v 0.07 déjà. Évalué à 1.
Ce temps de découverte du schéma de la table via un DESC est beaucoup plus infime que s'il avait à accéder à un fichier xml en lecture ecriture + parsing comme les autres ORM.
Au niveau des 10 000 lignes cela ne change rien, ta table peut également stocker 1 000 000 d'enregistrements.
C'est l'optimisation de ta requête SQL qui est importante, et ça il n'y a que toi qui peut le faire.
PMO est une couche d'abstraction objet c'est aussi de la plomberie, c'est sur que ça n'est pas aussi bien que si c'était un module PHP à part entière car il utilise d'autres couches d'abstraction en dessous .