[disclaimer]
Je connais plus Oracle que MySQL/Postgres mais je suppose qu'on retrouve à peu près les même possibilités.
[/disclaimer]
Pouvoir "séparer" les requête sql du code j'aime beaucoup l'idée, si on change de langage pour travailler sur la même base de données ça doit faire gagner beaucoup de temps.
Ca peut aider mais pas tant que ça. Les procédures servent surtout pour l'écriture, très peu pour la lecture et on effectue souvent plus de lecture/recherche que d'écriture. Ca évite surtout de dupliquer du code ou d'oublier de mettre à jour certaines informations.
Aussi j'imagine que comme les procédures sont compilé il doit y avoir un bon gain de performance comparé aux traitement que je fait pour le moment en PHP.
Tout dépend ce que tu fais. Encore une fois on fait plus de lecture que d'écriture. Si tu construis tes requêtes dans le code tu prends cher deux fois. Tu as déjà le coût de multiples concaténation de strings pour au final construire toujours la même string (à part les valeurs passées).
Ensuite, une procédure stockée permet au RDBMS de mettre le plan d'exécution en cache et de n'avoir pas à refaire un hard parsing à chaque fois. Sur ce point, on peut obtenir des performances à peu près équivalentes en passant par des variables pour les requêtes récurrentes. Lorsqu'un RDBMS rencontre une requête (dans le cas d'Oracle en tous cas), il vérifie s'il n'a pas déjà rencontré la même (et donc s'il a le plan en cache). Or si on passe des requêtes qui ne diffèrent que par les valeurs, pour le système ce sont des requêtes différentes. Si on passe par des variables, il identifie qu'il s'agit de la même requête.
vous les utilisez ? est-ce que vous les utilisez pour tous ?
Pour tout, non. On peut difficilement "tout" faire uniquement avec. Je les utilise beaucoup pour des opérations type insert/update : Si le code passé est nul c'est une insertion, s'il est rempli c'est une mise à jour. Sinon ça sert pas mal pour supprimer une donnée et celles qui en dépendent. Ca évite d'écrire plusieurs delete et d'en oublier un (violation de contraintes, toussa). Idem pour les opérations d'insertion complexe (ajout d'un entrée et mise à jour dans une autre table).
# Procédure stockées
Posté par Croconux . En réponse au message Procédure stockées. Évalué à 2.
Je connais plus Oracle que MySQL/Postgres mais je suppose qu'on retrouve à peu près les même possibilités.
[/disclaimer]
Pouvoir "séparer" les requête sql du code j'aime beaucoup l'idée, si on change de langage pour travailler sur la même base de données ça doit faire gagner beaucoup de temps.
Ca peut aider mais pas tant que ça. Les procédures servent surtout pour l'écriture, très peu pour la lecture et on effectue souvent plus de lecture/recherche que d'écriture. Ca évite surtout de dupliquer du code ou d'oublier de mettre à jour certaines informations.
Aussi j'imagine que comme les procédures sont compilé il doit y avoir un bon gain de performance comparé aux traitement que je fait pour le moment en PHP.
Tout dépend ce que tu fais. Encore une fois on fait plus de lecture que d'écriture. Si tu construis tes requêtes dans le code tu prends cher deux fois. Tu as déjà le coût de multiples concaténation de strings pour au final construire toujours la même string (à part les valeurs passées).
Ensuite, une procédure stockée permet au RDBMS de mettre le plan d'exécution en cache et de n'avoir pas à refaire un hard parsing à chaque fois. Sur ce point, on peut obtenir des performances à peu près équivalentes en passant par des variables pour les requêtes récurrentes. Lorsqu'un RDBMS rencontre une requête (dans le cas d'Oracle en tous cas), il vérifie s'il n'a pas déjà rencontré la même (et donc s'il a le plan en cache). Or si on passe des requêtes qui ne diffèrent que par les valeurs, pour le système ce sont des requêtes différentes. Si on passe par des variables, il identifie qu'il s'agit de la même requête.
vous les utilisez ? est-ce que vous les utilisez pour tous ?
Pour tout, non. On peut difficilement "tout" faire uniquement avec. Je les utilise beaucoup pour des opérations type insert/update : Si le code passé est nul c'est une insertion, s'il est rempli c'est une mise à jour. Sinon ça sert pas mal pour supprimer une donnée et celles qui en dépendent. Ca évite d'écrire plusieurs delete et d'en oublier un (violation de contraintes, toussa). Idem pour les opérations d'insertion complexe (ajout d'un entrée et mise à jour dans une autre table).