Question

Je cite une partie d'une réponse que j'ai reçue pour une autre de mes questions :

  

Dans le monde PHP / MySQL, je dirais   les procédures stockées sont no-go

Je voudrais savoir: est-ce vrai? Pourquoi? Pourquoi pas?

[edit] Je veux dire ceci comme une question générale sans besoin spécifique à l'esprit [/ edit]

Était-ce utile?

La solution

Je développe et gère une grande application PHP / MySQL. Voici mon expérience des procédures stockées.

Au fil du temps, notre application est devenue très complexe. Et avec toute la logique côté php, certaines opérations interrogeraient la base de données avec plus de 100 requêtes courtes.

MySQL est si rapide que les performances étaient toujours acceptables, mais pas excellentes.

Dans notre dernière version du logiciel, nous avons pris la décision de déplacer une partie de la logique vers des procédures stockées pour des opérations complexes.

Nous avons réalisé des gains de performances significatifs car nous n’avions pas à envoyer de données entre PHP et MySQL.

Je suis d'accord avec les autres afficheurs que PL / SQL n'est pas un langage moderne et qu'il est difficile à corriger.

Bottom Line: Les procédures stockées sont un excellent outil pour certaines situations. Mais je ne recommanderais pas de les utiliser sauf si vous avez une bonne raison. Pour les applications simples, les procédures stockées ne valent pas la peine.

Autres conseils

Lors de l'utilisation de procédures stockées avec MySQL, vous devrez souvent utiliser le mysqli interface en PHP et non l'interface mysql .

La raison en est que les procédures stockées renvoient souvent plus d'un jeu de résultats. Si c'est le cas, l'API mysql ne peut pas le gérer et vous obtiendrez des erreurs.

L’interface mysqli a des fonctions pour gérer ces multiples résultats, telles que mysqli_more_results et mysqli_next_result .

N'oubliez pas que si vous renvoyez un ensemble de résultats de la procédure stockée, vous devez utiliser ces API, car la procédure stockée génère un jeu de résultats pour l'exécution réelle, puis un autre pour chaque jeu de résultats. renvoyé intentionnellement à partir de la procédure stockée.

En général, je reste à l’écart des procédures stockées car cela ajoute de la charge à la base de données, ce qui représente 99% du temps, votre plus gros goulot d’étranglement. Ajouter un nouveau serveur php n’est rien comparé à la réplication de votre base de données MySQL.

Avez-vous un besoin spécifique en tête qui vous fait les considérer? Les procédures stockées sont beaucoup moins portables que les procédures "simples". SQL, c'est généralement pourquoi les gens ne veulent pas les utiliser. De plus, après avoir écrit une bonne part de PL / SQL, je dois dire que la façon procédurale d’écrire du code ajoute à la complexité et qu’elle n’est tout simplement pas très moderne ni testable. Ils peuvent être utiles dans certains cas particuliers où vous devez optimiser, mais je réfléchirais certainement à deux fois. Jeff a des avis similaires .

C’est une question subjective.

J'inclurais personnellement tous les calculs dans PHP et n'utilisais vraiment que MySQL comme table.

Mais, si vous estimez qu'il est plus facile d'utiliser des procédures stockées, alors allez-y, faites-le.

Je ne dirais pas que les "procédures stockées sont un non-droit", je dirais "ne les utilisez pas sans raison valable".

Les procédures stockées MySQL ont une syntaxe particulièrement horrible (Oracle et MSSQL sont également assez horribles), leur maintenance ne fait que compliquer votre application.

Utilisez une procédure stockée si vous avez une raison réelle (mesurable) de le faire, sinon, ne le faites pas. C'est mon avis quand même.

Il existe peut-être une phobie des procédures stockées avec mysql, due en partie au fait qu’elle n’est pas extrêmement puissante (comparé à Postgresql et même à MSSQL, les procédures stockées mysqls font grandement défaut).

Sur le plus: ils facilitent l’interface avec plusieurs langues.

Si quelqu'un déclare que " utiliser des procédures stockées est mauvais, car il n'est pas portable vers différentes bases de données ". cela signifie bien sûr qu'ils pensent que vous êtes sur le point de changer de base de données, ce qui signifie qu'ils disent à leur tour qu'ils ne devraient pas utiliser mysql.

Il est courant d'utiliser les ORM de nos jours, mais je pense personnellement que ORM est un BadThing ( Question : 82882 )

Je pense que l’utilisation de procédures stockées peut offrir une certaine abstraction dans certaines applications, car dans les cas où vous utiliseriez le même bloc de code SQL pour mettre à jour ou ajouter les mêmes données, vous pouvez ensuite créer le fichier sproc save_user ($ attr .. ...) plutôt que de vous répéter partout.

Il est convenu que la syntaxe est poilue et que si vous êtes habitué à MSSQL et à Oracle, il existe des différences qui peuvent être frustrantes.

Vous devez également savoir que les procédures stockées n'étaient pas prises en charge dans Mysql avant la version 5.0. http://dev.mysql.com/doc/refman/ 5.0 / fr / storage-routines.html Les procédures stockées ont également tendance à être un peu bizarres dans cette implémentation. Maintenant que Mysql 5.1 commence à faire son apparition dans la nature, je constate une utilisation accrue des procédures stockées avec Mysql.

Je fais un usage limité des procédures stockées et cela fonctionne bien. Je suis le développeur principal de l'un des clients de mon entreprise, qui travaille sur son site Web e-comm. Le client a un système de stock, nous avons implémenté un ensemble de procédures stockées sur son système et construit une API pour communiquer avec lui. Cela nous a permis d'abstraire leur base de données et ils ont pu implémenter une logique dans les procédures stockées. Simple mais répondait très bien aux besoins de l'entreprise.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top