est-ce les procédures stockées de mysql sont plus rapides que le langage hote ?

bonjour,

je suis en train de développer un applicatif dont je souhaite le plus possible garder les fonctions métiers dans le sgbd (afin de limiter la partie graphique à du graphisme et à l'appel de function stockées dans mysql).

mais voilà, je me pose la question de la rapidité d'exécution d'une procédure stockées.

qu'est-ce qui est plus rapide en général ? la faire procédure stockée ou la faire en langage php ?

par exemple, j'ai une table produit, et acheteur. Chaque fois que j'ajoute un acheteur, je veux que le prix d'un produit baisse en fonction du nombre d'acheteur (c'est juste un exemple).

en php, en gros ça fait une une requête count et une update qui arriveront juste après celle de l'insert (du achateur ajouté).

en procédure stockés, j'aurai aucune transaction entre le client, et le servuer, tout se fera en trigger via une procédure stockées. je me dis alors que ça devrait être plus rapide. non ?

question bête : 2 requêtes sql arrivent en même temps dans mysql. une provenant du client php, et l'autre provenant d'une fonction issu d'une procédure stockées. laquel sera prioritaire à l'intérieur du sgbd ? peut-on régler les procédures stockées pourqu'elles soient prioritaires et aient plus de ressources que les requêtes externes cliente ?

j'ai entendu bcp de bien du langage de oracle et sql server pour les procédures stockées mais rien sur MySQL.

merci de vos conseils

Les procédures stockées s'affranchissent des transports de données (que ce soit en mémoire ou sur le réseau) entre le SGBD et le logiciel consommateur.

Elles sont donc plus rapide pour la manipulation de données, notamment sur de gros volumes ou lors de traitements intensifs (multiples lectures/écritures).

En revanche, les PS sont prévues pour traiter des données de manière ensembliste. Les traitements procéduraux sont donc assez lents.

De même, pour les traitements qui ne sont pas directement sur les données, un langage hôte (PHP, Java, C#, etc.) sera généralement plus rapide.

En règle générale, on privilégie les traitements de données dans des procédures stockées/triggers, et la mise en forme du résultat, les calculs, dans la partie cliente.

Attention tout de même : vous êtes avec MySQL, le mauvais élève des SGBD, vous pouvez avoir de grosses surprises.

Citation:

---

Envoyé par StringBuilder

En règle générale, on privilégie les traitements de données dans des procédures stockées/triggers, et la mise en forme du résultat, les calculs, dans la partie cliente.

---

d'où cela vient-il ? d'expérience ou d'apprentissage (dit par un prof) ou via le manuel ou un livre ?

disons que j'ai un calcul particulier d'une remise cliente ou d'un cout de revient ou qu'un quota. autant que ce soit fait en PS plutôt que par le système hôte car si ça change tout le temps (la méthode calcul), comme ça y a pas à modifier les multiples versions interfacées (version site internet, version mobile, version client lourd) . non ?

je ne sais plus où j'ai entendu ou lu ça, mais je pensais que tout ce qui était métier, devait (ou devrait, ou doit ou pourrait ) être le plus possible du language bas (sgbd).

Citation:

---

par exemple, j'ai une table produit, et acheteur. Chaque fois que j'ajoute un acheteur, je veux que le prix d'un produit baisse en fonction du nombre d'acheteur (c'est juste un exemple).

---

Faites-le faire par le SGBD puisqu'il s'agit d'un traitement sur les données sans intervention de l'utilisateur de l'application.
Un simple trigger fait l'affaire je pense.

Citation:

---

en php, en gros ça fait une une requête count et une update qui arriveront juste après celle de l'insert (du achateur ajouté).

en procédure stockés, j'aurai aucune transaction entre le client, et le server, tout se fera en trigger via une procédure stockées. je me dis alors que ça devrait être plus rapide. non ?

---

Exactement !
Le temps de transfert des données entre l'applicatif et le SGBD sera probablement plus grand que de tout traiter au sein du SGBD.

Citation:

---

question bête : 2 requêtes sql arrivent en même temps dans mysql. une provenant du client php, et l'autre provenant d'une fonction issu d'une procédure stockées. laquel sera prioritaire à l'intérieur du sgbd ?

---

Les SGBD sont prévus pour travailler avec de multiples connexions.
Premier arrivé, premier servi et les autres attendent à la porte s'ils s'adressent à la même table pendant que celle-ci est modifiée par le premier.

Citation:

---

disons que j'ai un calcul particulier d'une remise cliente ou d'un cout de revient ou qu'un quota.

---

Calcul sur les données sans intervention de l'utilisateur : en SGBD !

Citation:

---

je ne sais plus où j'ai entendu ou lu ça, mais je pensais que tout ce qui était métier, devait (ou devrait, ou doit ou pourrait ) être le plus possible du language bas (sgbd).

---

C'est le principe du développement en base de données épaisse.

Salut, j'ai pas lu toutes les réponses, j'imagine que tu as déjà eu ta réponse, mais je viens ajouter ma petite pierre.

Oui, il est toujours préférable (je n'ai pas encore rencontré de situation où ce n'était pas le cas) d'utiliser des procédures stockées de ton SGBD au lieu d'utiliser / traiter des données en PHP (ou n'importe quel autre langage).

Citation:

---

Envoyé par CleeM

Oui, il est toujours préférable (je n'ai pas encore rencontré de situation où ce n'était pas le cas) d'utiliser des procédures stockées de ton SGBD au lieu d'utiliser / traiter des données en PHP (ou n'importe quel autre langage).

---

Je veux bien qu'on soit pro-SGBD mais quand même...
Il faudrait cesser les généralités comme celle-là. Si c'était tellement une évidence, tout le monde développerait de cette façon.

Citation:

---

Envoyé par FSiebert

Je veux bien qu'on soit pro-SGBD mais quand même...
Il faudrait cesser les généralités comme celle-là. Si c'était tellement une évidence, tout le monde développerait de cette façon.

---

si déjà au niveau terminal on apprenait qu'un SGBD peut faire autre chose que select,insert , delete, create,grant ce serait déjà pas mal!

Bun oui un sgbd peut faire upper et lower,md5 alors pourquoi occuper le pauvre apache à faire ces tâches banales alors que monsieur oracle peut le faire en amont/aval. Autant laisser apache faire ce qu'il sait faire de mieux et que le sgbd ne fait pas à sa place.

Citation:

---

Envoyé par Michael REMY

si déjà au niveau terminal on apprenait qu'un SGBD peut faire autre chose que select,insert , delete, create,grant ce serait déjà pas mal!

Bun oui un sgbd peut faire upper et lower,md5 alors pourquoi occuper le pauvre apache à faire ces tâches banales alors que monsieur oracle peut le faire en amont/aval. Autant laisser apache faire ce qu'il sait faire de mieux et que le sgbd ne fait pas à sa place.

---

Je suis entièrement d'accord :)
Je critiquais simplement la généralisation qui risquait d'être prise pour argent comptant par des débutants.
Dans certains cas, utiliser des procédures stockées, ce n'est même pas possible, dans certains cas c'est parfaitement adapté, dans certains cas ça se discute.
Le choix de la solution technique doit être réfléchi.

Citation:

---

Envoyé par Michael REMY

d'où cela vient-il ? d'expérience ou d'apprentissage (dit par un prof) ou via le manuel ou un livre ?

---

Un peu tout à la fois.

Pour moi, calculer une remise, c'est un traitement.

Ce que je veux dire par "calcul", c'est par exemple afficher l'age d'une personne à partir de sa date de naissance.
C'est inutile de faire faire le calcul à la base de données, autant le faire côté client. Comme ça, le jour où tu veux en plus dire "tiens, c'est son anniversaire dans 5 jours", tu n'as pas besoin de modifier ta requête/vue, t'as juste à rajouter un calcul dans le client.

Oui et non !

Si tu as 150 000 personnes dans la table et que tu as une routine qui fait quelque chose la semaine de leur anniversaire, tu as intérêt à n'extraire que les personnes dont c'est l'anniversaire prochainement à l'aide d'une requête SQL plutôt que de récupérer les 150 000 personnes et analyser ça dans le logiciel.

Par contre, afficher l'âge des quelques personnes affichées à l'écran peut se faire à la volée dans le logiciel en ne récupérant que la date de naissance brute de ces quelques personnes.

Le SGBD est champion pour les traitement de données en masse.
Il ne faut extraire de la BDD que ce dont on a besoin pour l'affichage et le traitement immédiat de ce qui est à afficher.

Je parle "d'afficher l'âge".

Rechercher toutes les personnes dont l'anniversaire est dans 5 jours pour envoyer un mail, c'est un traitement, donc PL.

En revanche, quand on est sur un forum par exemple, et qu'on consulte un topic, afficher l'âge du posteur et une icône pour dire que son anniv c'est dans 5 jours, ça doit se faire côté client : les règles peuvent aisément changer, et il n'y a aucune valeur ajouté à le faire côté SGBD puisqu'on ne filtre pas dessus, qu'on ne le stocke pas, et que le jeu de résultat ne dépends pas du calcul.

salut,

en fait, presque tout peut être fait en procédural si on ne cherche pas à faire n'importe quoi comme chercher à changer les lignes en colonnes (transposition d'un tableau) qui sont, certes faisables (souvent) mais qui sont un non sens en terme de lourdeur de traitement, par rapport à n'importe quel langage...
en gros, faut être raisonnable...:aie:

avec les UDF et les événements gérés en internes plus besoin de cron ou de traitement genre mail, preg_replace, preg_match, etc... en externe... sous réserve que ton hébergeur te les autorise...

donc faire de la bd épaisse n'est pas un soucis sous réserve que tu aies un dédié, la plupart du temps... sinon faudra te résoudre à garder quand même un certain nombre de choses coté langage applicatif...

après faut aussi dire que c'est plus efficace sur certains sgbd (postgresql, oracle, etc...) que mysql car ils compilent les SP à la création et proposent parfois plusieurs langages autres que SQL..

néanmoins, il est toujours plus rentable de faire des SP ne serait ce que pour isoler le langage applicatif par rapport au sql...

Pour moi, ça reste une question de volonté, de bon sens dans ce qu'on veut faire et de possibilité d'hébergement... :ccool: