Faire des calculs en MySQL vs PHP

Je jouerais sur les points forts 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 faire exactement 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 plates-formes de base de données que j'ai utilisées ont des fonctionnalités très médiocres pour travailler avec des valeurs individuelles. Des choses comme le formatage de date et la manipulation de chaînes sont tout simplement nulles en SQL, vous feriez mieux de faire ce travail en PHP.

Fondamentalement, utilisez chaque système pour ce pour quoi il est conçu.

En termes de maintenabilité, tant que la division entre ce qui se passe et où est claire, les séparer en types de logique ne devrait pas causer beaucoup de problèmes et certainement pas assez pour é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, mais les dates sont presque un cas particulier. Vous voulez vous assurer que toutes les dates générées par le système sont créées soit sur le serveur Web OU la base de données. Sinon, cela entraînera des bogues insidieux si le serveur de base de données et le serveur Web sont configurés pour des fuseaux horaires différents (j'ai vu cela se produire). Imaginez, par exemple, que vous ayez une createdDate colonne avec une valeur par défaut de getDate() qui est appliqué à l'insertion par la BD . Si vous deviez insérer un enregistrement, utilisez 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 n'obtiendrez peut-être pas ce que vous attendez. En ce qui concerne la couche sur laquelle vous devez faire cela, je privilégierais 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. Combiner prénom et 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é base de données signifie que vous finissez par déplacer plus de données, même si c'est vraiment mineur.

3. Dépend. Comme ci-dessus, si jamais vous souhaitez les utiliser séparément, vous feriez mieux de les retirer séparément et de les concaténer en cas de besoin. Cela dit, à moins que les ensembles de données que vous traitez ne soient énormes, il y a probablement d'autres facteurs (comme, comme vous l'avez mentionné, la maintenabilité) qui ont plus d'incidence.

Quelques règles de base :

• La génération d'identifiants incrémentiels doit se produire dans la base de données.
• Personnellement, j'aime ma valeur par défaut appliquée 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é base de données (comme avec l'exemple de chaînes ci-dessus).
• Et comme vous dites ; le classement, l'agrégation, les sous-requêtes, les jointures, etc. doivent toujours être côté base de données.
• 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 auxquels vous devez faire face ici et l'équilibre dépend vraiment de votre application.

Certaines choses devraient certainement, à chaque fois, toujours être faites en SQL. L'exclusion de certaines exceptions (comme les dates) pour de nombreuses tâches SQL peut être très maladroite et peut vous laisser avec une logique dans des endroits éloignés. 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.

La performance est toujours une considération mais, selon votre application et l'exemple spécifique, peut-être pas un gros problème. Vos préoccupations concernant la maintenabilité sont probablement très valables et certains des avantages en termes de performances que j'ai mentionnés sont très légers, alors méfiez-vous de l'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 d'une plus grande 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 serait réutilisable est implémenté dans SQL.

Réponse courte :ça dépend. :)