Quelle est l'alternative aux curseurs pour extraire de grandes quantités de données d'une base de données?

Question

En parcourant stackoverflow j'ai trouvé un grand nombre de réponses condamnant l'utilisation de curseurs dans la programmation de base de données. Cependant, je ne comprends pas vraiment quelle est l'alternative.

Je crée un programme qui lit un grand nombre de lignes (des centaines de milliers) de la base de données et les garde en mémoire, pour des raisons de performances. Je ne peux pas vraiment lancer une table SELECT * FROM et traiter tous les résultats en même temps, n'est-ce pas?

Le meilleur moyen que j'ai trouvé est d'utiliser des curseurs et de récupérer les lignes par incréments, par exemple 10 à la fois.

Quelqu'un pourrait-il m'éclairer? J'utilise PostgreSQL 9 sur Linux.

Merci

Answer 1

Jetez un oeil à LIMIT and OFFSET

Answer 2

Un curseur est la meilleure option lorsque vous devez traiter de grandes quantités de données. Vous pouvez également utiliser la méthode LIMIT .. OFFSET .., mais cela deviendra de plus en plus lent, en fonction de la quantité de données. PostgreSQL n'a aucun problème avec les curseurs, utilisez-les lorsque vous gérez de grandes quantités de données.

SQL Server a/avait des problèmes avec les curseurs, MySQL ne peut pas gérer les curseurs en dehors des fonctions stockées, ce qui pourrait être la raison pour laquelle certains dba ne aiment pas les curseurs.

Answer 3

Vous pouvez utiliser straightly la boucle en utilisant enregistrement:

do 
$$ 
declare r record; 

begin 

    for r in select product_id, name from products loop 
     raise notice '% %', r.product_id, r.jname; 
    end loop; 

end$$ 

Answer 4

Je suppose que la meilleure façon est d'utiliser COPY pour obtenir des données nécessaires directement à votre application cliente.

Je n'ai également eu aucun problème lors de l'utilisation des curseurs. Pour autant que je sache, le curseur conserve un instantané des données pour vous, et formellement il (et COPY) est le seul moyen correct de parcourir les résultats, sinon l'utilisation de LIMIT..OFFSET peut entraîner des incohérences, car le décalage est modifié par les enregistrements nouvellement insérés.

Answer 5

Il devrait être rare d'avoir besoin d'un curseur. Peut-être que si votre logique change lorsque chaque rangée précédente est mise à jour, alors vous aurez peut-être besoin d'un curseur.

Avez-vous vraiment besoin d'ouvrir un curseur pour votre problème? Pouvez-vous donner les détails de ce que vous essayez de faire? Les grands ensembles de données sont une bonne raison d'éviter les curseurs, pas une raison de les utiliser.

Vous devez essayer de traiter les ensembles. Juste des mises à jour régulières sur les tables, avec des jointures et où des filtres. Une simple mise à jour peut-elle remplacer votre boucle de curseur?

Answer 6

Si vous ne faites que télécharger des données, pourquoi ne pas utiliser select? Vous n'économisez pas de mémoire en tirant 10 lignes à la fois parce que votre mise en cache tout dans la mémoire de toute façon.

Ai-je raté quelque chose?