web-dev-qa-db-fra.com

Faire des calculs dans MySQL vs PHP

Le contexte:

  • Nous avons une application PHP/MySQL.
  • Certaines parties des calculs sont effectuées directement en SQL. Par exemple: tous les utilisateurs créés au cours des dernières 24 heures seront renvoyés via une requête SQL (MAINTENANT () - 1 jour)

Il y a un débat en cours entre un collègue développeur et moi où je pense que nous devrions:

A. Conservez tous les calculs/code/logique dans PHP et traitez MySQL comme un référentiel d'informations "stupide"

Son opinion:

B. Faites un mix and match en fonction de ce qui est plus facile/plus rapide. http://www.onextrapixel.com/2010/06/23/mysql-has-functions-part-5-php-vs-mysql-performance/

Je regarde du point de vue de la maintenabilité. Il regarde la vitesse (qui, comme le souligne l'article, certaines opérations sont plus rapides dans MySQL).

@ bob-the-destroyer @tekretic @OMG Ponies @mu est trop court @Tudor Constantin @tandu @Harley

Je suis d'accord (et bien évidemment) les clauses WHERE efficaces appartiennent au niveau SQL. Cependant, qu'en est-il des exemples comme:

  1. Calcul d'une période de 24 à l'aide de NOW () - 1 jour en SQL pour sélectionner tous les utilisateurs créés au cours des dernières 24 heures?
  2. Retourner le prénom et le nom en majuscule de tous les utilisateurs?
  3. Concaténer une chaîne?
  4. (pensées, gens?)

Exemples clairs appartenant au domaine SQL:

  1. sélections spécifiques OERE
  2. Instructions SQL imbriquées
  3. Commande/tri
  4. Sélection des éléments DISTINCT
  5. Compter les lignes/articles
phpmysqlperformancemaintainability
49
siliconpi

Je jouerais avec les forces de chaque système.

La logique d'agrégation, de jointure et de filtrage appartient évidemment à la couche de données. C'est plus rapide, non seulement parce que la plupart des moteurs de base de données ont plus de 10 ans d'optimisation pour cela, mais vous minimisez les données transférées entre votre base de données et votre serveur Web.

D'un autre côté, la plupart des plateformes DB que j'ai utilisées ont des fonctionnalités très médiocres pour travailler avec des valeurs individuelles. Les choses aiment le formatage de la date et la manipulation de chaînes, tout simplement nul en SQL, vous feriez mieux de faire ce travail en PHP.

Fondamentalement, utilisez chaque système pour ce qu'il est conçu pour faire.

En termes de maintenabilité, tant que la division entre ce qui se passe est claire, la séparation de ceux-ci avec des types de logique ne devrait pas poser beaucoup de problèmes et certainement pas assez pour en éliminer les avantages. À mon avis, la clarté et la maintenabilité du code sont plus une question de cohérence que de mettre toute la logique au même endroit.

Re: exemples spécifiques ...

  1. Je sais que ce n'est pas ce à quoi vous faites référence aussi, mais les dates sont presque un cas spécial. Vous voulez vous assurer que toutes les dates générées par le système sont créées soit sur le serveur Web OR la base de données. Sinon, cela provoquera des bogues insidieux si le serveur de base de données et le serveur Web sont configurés pour différents fuseaux horaires (j'ai vu cela se produire). Imaginez, par exemple, que vous avez une colonne createdDate avec une valeur par défaut de getDate() qui est appliquée lors de l'insertion par la DB. Si vous deviez insérer un enregistrement puis, en utilisant une date générée en PHP (par exemple date("Y-m-d", time() - 3600), sélectionnez les enregistrements créés au cours de la dernière heure, vous pourriez ne pas obtenir ce que vous Quant à la couche sur laquelle vous devez le faire, je préférerais la base de données car, comme dans l'exemple, elle vous permet d'utiliser les valeurs par défaut des colonnes.

  2. Pour la plupart des applications, je le ferais en PHP. La combinaison du prénom et du nom de famille semble simple jusqu'à ce que vous réalisiez que vous avez parfois besoin de salutations, de titres et d'initiales. De plus, vous allez presque certainement vous retrouver dans une situation où vous voulez un prénom, un nom de famille ET une combinaison salutation + prénom + nom de famille. Les concaténer côté DB signifie que vous finissez par déplacer plus de données, bien que ce soit vraiment mineur.

  3. Dépend. Comme ci-dessus, si vous souhaitez les utiliser séparément, vous feriez mieux de les retirer séparément et de les concaténer si nécessaire. Cela dit, à moins que les ensembles de données avec lesquels vous traitez soient énormes, il y a probablement d'autres facteurs (comme, comme vous le mentionnez, la maintenabilité) qui ont plus d'incidence.

Quelques règles d'or:

  • La génération d'ID incrémentiels doit se produire dans la base de données.
  • Personnellement, j'aime mon défaut appliqué par la DB.
  • Lors de la sélection, tout ce qui réduit le nombre d'enregistrements doit être effectué par la base de données.
  • Il est généralement bon de faire des choses qui réduisent la taille de l'ensemble de données côté DB (comme avec l'exemple de chaînes ci-dessus).
  • Et comme vous dites; l'ordre, l'agrégation, les sous-requêtes, les jointures, etc. doivent toujours être côté DB.
  • De plus, nous n'en avons pas parlé, mais les déclencheurs sont généralement mauvais/nécessaires.

Il y a quelques compromis de base à affronter ici et l'équilibre dépend vraiment de votre application.

Certaines choses devraient toujours être effectuées à chaque fois en SQL. Exclure certaines exceptions (comme la date) pour de nombreuses tâches SQL peut être très maladroit et peut vous laisser une logique à l'écart des endroits. Lorsque vous recherchez dans votre base de code des références à une colonne spécifique (par exemple), il est facile de manquer celles contenues dans une vue ou une procédure stockée.

Les performances sont toujours une considération mais, selon votre application et l'exemple spécifique, ce n'est peut-être pas un gros problème. Vos préoccupations concernant la maintenabilité et probablement très valables et certains des avantages de performance que j'ai mentionnés sont très légers, alors méfiez-vous d'une optimisation prématurée.

De plus, si d'autres systèmes accèdent directement à la base de données (par exemple pour les rapports ou les importations/exportations), vous bénéficierez de plus de logique dans la base de données. Par exemple, si vous souhaitez importer directement des utilisateurs à partir d'une autre source de données, quelque chose comme une fonction de validation d'e-mail réutilisable est implémenté dans SQL.

Réponse courte: cela dépend. :)

41
Molomby

Je n'aime pas réinventer la roue. J'aime aussi utiliser le meilleur outil possible pour la tâche à accomplir, donc:

  • Lorsque je peux obtenir le jeu de résultats directement à partir de DB sans traitement supplémentaire, je le fais - votre cas, c'est une simple requête avec une simple clause WHERE. Imaginez ce qui se passe lorsque vous avez 10 millions d'utilisateurs et que vous les transférez en PHP, juste pour en avoir besoin de 100 - vous l'aurez deviné - il est très possible que votre serveur web plante
  • Lorsque vous avez besoin d'obtenir des données de 2 tables ou plus à la fois, encore une fois, MySQL est beaucoup meilleur que PHP
  • Lorsque vous devez compter des enregistrements - la base de données est excellente
  • J'ai tendance à privilégier le traitement au niveau de l'application aux contraintes FK
  • De plus, j'ai tendance à éviter les procédures stockées, préférant implémenter cette logique métier au niveau de l'application (sauf si, bien sûr, nous parlons d'énormes ensembles de données).

En conclusion, je dirais que votre collègue a raison dans le cas présenté

8
Tudor Constantin

Si vous mettez la moitié de votre logique dans la base de données et l'autre moitié dans le php, puis 6 mois plus tard lorsque vous apportez une modification, il vous faudra deux fois plus de temps pour comprendre ce qui se passe.

Cela dit, vos requêtes de base de données devraient avoir juste assez de logique pour qu'elles fournissent à votre php exactement les données dont il a besoin. Si vous vous retrouvez à parcourir des milliers d'enregistrements mysql dans votre code php, vous faites quelque chose de mal. À l'autre extrémité de l'échelle, cependant, si vous exécutez des instructions if/else dans vos requêtes mysql, vous faites également quelque chose de mal (il suffit probablement de réécrire votre requête).

J'éviterais les procédures stockées. Bien qu'ils soient un excellent concept en théorie, vous pouvez généralement obtenir le même résultat dans le php avec un temps de développement beaucoup plus rapide et vous avez également l'avantage supplémentaire de savoir où se trouve toute la logique.

7
Harley

MySQL évoluera mieux à mesure que les ensembles de résultats augmentent. Franchement, traiter une base de données comme un référentiel de "données stupides" est un gaspillage de ressources ...

La maintenabilité a tendance à être entachée de familiarité. Si vous n'êtes pas familier avec PHP, ce ne serait pas votre premier choix pour la maintenabilité - n'est-ce pas?

6
OMG Ponies

Le temps nécessaire pour récupérer les données dans SQL prend du temps, mais une fois que ses calculs sont plus ou moins identiques. Cela ne prendra pas beaucoup de temps dans les deux cas après la récupération des données, mais le faire intelligemment dans le SQL peut donner de meilleurs résultats pour les grands ensembles de données.

Si vous récupérez des données à partir de MYSQL puis effectuez les calculs en PHP sur les données récupérées, il est préférable de récupérer le résultat requis et d'éviter le traitement de PHP , car cela augmentera plus de temps.

Quelques points de base:

  1. Le formatage de la date dans MYSQL est solide, la plupart des formats sont disponibles dans Mysql. Si vous avez un format de date très spécifique, vous pouvez le faire en PHP.

  2. La manipulation de chaînes ne fait que sucer en SQL, il vaut mieux faire cela en PHP. Si vous n'avez pas besoin de manipuler de grandes chaînes, vous pouvez le faire dans Mysql SELECTs.

  3. Lors de la sélection, tout ce qui réduit le nombre d'enregistrements doit être effectué par SQL et non par PHP

  4. Les données de commande doivent toujours être effectuées dans Mysql

  5. L'agrégation doit toujours être effectuée dans Mysql car les moteurs de base de données sont spécialement conçus pour cela.

  6. Les sous-requêtes et jointures doivent toujours être côté DB. Cela réduira vos quantités de PHP. Lorsque vous devez obtenir des données de 2 tables ou plus à la fois, encore une fois, SQL est bien meilleur que PHP

  7. Vous voulez compter les enregistrements, SQL est génial.

3
Somnath Muluk