Cela dépend de nombreux facteurs, mais le plus important :
- complexité des calculs (préférez effectuer des calculs complexes sur un serveur d'applications, car cela évolue hors; plutôt qu'un serveur de base de données, qui évolue vers le haut )
- volume de données (si vous avez besoin d'accéder/d'agréger beaucoup de données, le faire sur le serveur de base de données permettra d'économiser de la bande passante et du disque io si les agrégats peuvent être effectués à l'intérieur des index)
- commodité (sql n'est pas le meilleur langage pour le travail complexe - surtout pas génial pour le travail procédural, mais très bon pour le travail basé sur des ensembles ; mauvaise gestion des erreurs, cependant)
Comme toujours, si vous faites ramener les données au serveur d'application, minimiser les colonnes et les lignes sera à votre avantage. S'assurer que la requête est ajustée et correctement indexée aidera l'un ou l'autre scénario.
Concernant votre note :
puis parcourez les enregistrements
Boucle par le biais d'enregistrements est presque toujours la mauvaise chose à faire en sql - écrire une opération basée sur un ensemble est préférable.
En règle générale , je préfère réduire au minimum le travail de la base de données "stocker ces données, récupérer ces données" - cependant, il existe toujours des exemples de scénarios où une requête élégante sur le serveur peut économiser beaucoup de bande passante.
Considérez également :si cela est coûteux en calcul, peut-il être mis en cache quelque part ?
Si vous voulez un précis "ce qui est mieux"; codez-le dans les deux sens et comparez-le (en notant qu'un premier brouillon de l'un ou l'autre n'est probablement pas réglé à 100%). Mais tenez compte de l'utilisation typique :si, en réalité, il est appelé 5 fois (séparément) à la fois, alors simulez cela :ne comparez pas un seul "1 de ceux-ci contre 1 de ceux-ci".
