ORM résultats de requête: Tableaux vs Résultat enveloppé poignée dans l'interface Iterator

Question

D'accord, voici un pour les pros:

Depuis quelques années maintenant, je travaille sur mon propre implémentation PHP ORM / ActiveRecord que je peux nommer Iterator l'interface à la place d'un tableau. Il ne faut pas chercher instantanément tous les enregistrements du ResultSet, mais il suffit de maintenir la ressource de résultat pour la requête de base de données générée et utiliser mysql_fetch_ * en interne lorsque vous traversez l'objet comme si elle était un tableau.

Maintenant, nous arrivons à ma vraie question: Puis-je, sans aucun problème faire exactement cela? Bases de données sont en mesure de gérer plusieurs resultsets ouvertes, et les mélanger et de les garder en mémoire pendant un certain temps?

Par exemple, chercher 20 objets, les boucles, que chacun de ces 20 autres, 5 d'extraction Wich à leur tour aussi fetch 3 autres. Cela créerait une boucle où un certain nombre de poignées de résultat sera conservé en mémoire.

Je sais que je ne peux pas sérialiser un de ces objets, mais je vais être en mesure de mettre en œuvre ce sans aucun problème dans PHP5, ou seront des interfaces de base de données me donner des problèmes?

Answer 1

Cela dépend de la base de données que vous utilisez et la configuration de votre base de données.

Pour MySQL, vous devez vous assurer que vous utilisez des requêtes mises en mémoire tampon. Dans PDO vous définissez comme ceci:

$myPdo->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, true);

Cela signifie que toutes les données seront envoyées au client (pas le même que la récupération tout en PHP).

L'autre (probablement pire) alternative est d'ouvrir une nouvelle connexion de base de données chaque fois que vous détectez une requête en cours d'exécution avec un jeu de résultats encore ouvert.

La normale mysql_query() utilise une requête en mémoire tampon, ce qui va travailler avec plusieurs jeux de résultats.