Sql traitement par rapport à un traitement ASP.NET Runtime

Question

Je sais en général, il est une bonne pratique de se déplacer autant que possible le traitement de Sql Server à l'application (dans mon cas ASP.NET). Cependant, que faire si le traitement au niveau de l'application signifie que plus de 30 paramètres supplémentaires sont transmis au serveur Sql. Dans ce cas, vaut-il la peine de déplacer le traitement vers le serveur Sql?

Voici le dilemme spécifique que je suis face - procédure qui offrira une meilleure performance globale?

CREATE PROCEDURE MyProc1 
    @id int 
AS BEGIN 
    UPDATE MyTable 
    SET somevalue1 = somevalue1 + 1, 
     somevalue2 = somevalue2 + 1, 
     somevalue3 = somevalue3 + 1, 
     ... 
     somevalueN = somevalueN + 1 
    WHERE id = @id 
END 

Ou

CREATE PROCEDURE MyProc2 
    @id int, 
    @somevalue1 int, 
    @somevalue2 int, 
    @somevalue3 int, 
    ... 
    @somevalueN int 
AS BEGIN 
    UPDATE MyTable 
    SET somevalue1 = @somevalue1, 
     somevalue2 = @somevalue2, 
     somevalue3 = @somevalue3, 
     ... 
     somevalueN = @somevalueN 
    WHERE id = @id 
END 

J'utilise un hébergement géré, mais je suppose qu'il est valide de supposer que Sql Server et l'exécution ASP.NET se trouvent sur la même machine, de sorte que le transfert de données entre les deux seraient probablement assez rapide/négligeable (ou est-ce).

---

Les 30 paramètres sont fondamentalement nombreNuméroRésultats pour différents articles. Ainsi, chaque fois qu'un utilisateur de mon application Web attribue une nouvelle note à itemN, totalNumberOfRatingsItemN est incrémenté de 1. Dans la plupart des cas, la note sera attribuée à plusieurs éléments (mais pas nécessairement tous), donc totalNumberOfRatings n'est pas identique pour différents éléments.

Answer 1

Je vais faire une supposition sauvage que vous avez lu que SQL Server n'est pas l'endroit approprié pour faire des mathématiques. Je pense que SQL est tout à fait approprié pour faire une poignée d'opérations arithmétiques et d'opérations d'agrégation, comme SUM. Seule la mesure des deux implémentations dans des scénarios de charge réalistes peut dire à coup sûr.

Qu'est-ce que SQL ne convient pas pour des choses comme la régression multiple et l'inversion de la matrice.

Déplacement incrementors au niveau de l'application me semble comme un micro-optimisation qui est peu susceptible de payer lui-même. Implémentez la logique pour incrémenter les valeurs dans les deux niveaux qui rendent le code lisible et maintenable.

Answer 2

Est-ce que la performance critique dans ce cas? Si ce n'était pas le cas, j'irais personnellement vers la lisibilité et la maintenabilité - ce qui signifierait la mise en œuvre selon les mêmes normes que le reste du système.

Answer 3

en général, il est une bonne pratique de se déplacer autant que possible le traitement de Sql Server à l'application

Qui dit ça? SQL Server est bon pour certaines choses, pas très bon pour d'autres. Utilisez votre jugement.

et par "application", voulez-vous dire

• la page Web
• une couche service d'application
• un composant de bus de services d'entreprise
• un service web
• quelque chose d'autre?

Il y a beaucoup de choix ...

Quant à votre question, incrémenter 30 champs semble risible. Passer 30 paramètres semble excessif. Certains contexte pour ...

Answer 4

Je recommande de normaliser votre tableau pour éliminer les 30 colonnes et plus. Au lieu de cela, envisager d'avoir une table avec une seule colonne de notation et ayant une ligne pour chaque élément différent, comme si:

CREATE TABLE ItemRatings 
(
    myTableId INT NOT NULL, -- Foreign key 
    itemNumber INT NOT NULL, 
    itemRating INT 
); 

Vous pouvez ensuite incrémenter un tas de notes à la fois avec une requête comme

UPDATE ItemRatings 
    SET itemRating = itemRating + 1 
WHERE myTableId = @id 
     AND itemNumber IN (@n1, @n2, @n3, ...) 

Quelque chose comme ça, de toute façon. Je ne comprends pas très bien comment fonctionnent vos tables puisque vous avez anonymisé tous les noms, mais j'espère que vous comprenez l'essentiel de ce que je dis. Cela dit, si vous ne voulez pas ou ne pouvez pas normaliser votre table de cette façon, je suis d'accord avec les autres réponses. C'est six sur un, une demi-douzaine sur l'autre. Personnellement, je choisirais la première solution et laisserais la base de données faire tout le travail. Bien sûr, comme dans toutes les choses, si la performance est ultra-critique alors la vraie réponse est de ne pas deviner; essayez les deux façons et sortez votre chronomètre!