Dois-je vraiment utiliser des transactions dans des procédures stockées ?[MSSQL2005]

Question

J'écris un message assez simple e-commerce app dans asp.net, dois-je utiliser des transactions dans mes procédures stockées ?

Le rapport lecture/écriture est d'environ 9:1

Answer 1

Beaucoup de gens demandent : ai-je besoin de transactions ?Pourquoi en ai-je besoin ?Quand les utiliser ?

La réponse est simple :utilisez-les tout le temps, sauf si vous avez une très bonne raison de ne pas le faire (par exemple, n'utilisez pas de transactions atomiques pour des « activités de longue durée » entre entreprises).La valeur par défaut devrait toujours être oui.Vous avez un doute ?- utiliser les transactions.

Pourquoi les transactions sont-elles bénéfiques ?Ils vous aident à gérer les plantages, les échecs, la cohérence des données, la gestion des erreurs, ils vous aident à écrire du code plus simple, etc.Et la liste des avantages continuera de s’allonger avec le temps.

Voici quelques informations supplémentaires de http://blogs.msdn.com/florinlazar/

Answer 2

N'oubliez pas que dans SQL Server, toutes les opérations CRUD à instruction unique sont par défaut dans une transaction implicite.Il vous suffit d'activer les transactions explicites (BEGIN TRAN) si vous devez faire en sorte que plusieurs instructions agissent comme une unité atomique.

Answer 3

La réponse est que cela dépend.Vous n'avez pas toujours besoin de sécurité des transactions.Parfois, c'est exagéré.Parfois, ce n'est pas le cas.

Je peux voir que, par exemple, lorsque vous mettez en œuvre un processus de paiement, vous ne souhaitez le finaliser qu'une fois que vous avez rassemblé toutes les données, etc.Pensez à un paiement, vous pouvez annuler - c'est un exemple lorsque vous avez besoin d'une transaction.Ou peut-être quand il est judicieux de les utiliser.

Avez-vous besoin d'une transaction lorsque vous créez un nouveau compte utilisateur ?Peut-être que s'il s'agit de 10 tables (pour une raison quelconque), s'il ne s'agit que d'une seule table, ce n'est probablement pas le cas.

Cela dépend aussi de ce que vous avez vendu à votre client et de qui il est, et s'il l'a demandé, etc.Mais si la décision vous appartient, alors je vous dirais de choisir judicieusement.

Mon objectif est d’éviter une optimisation prématurée.Créez votre application, gardez à l'esprit que vous souhaiterez peut-être revenir en arrière et refactoriser/optimiser plus tard lorsque vous en aurez besoin.Regardez quelques projets open source et voyez comment ils ont implémenté différentes parties de leur application, apprenez-en.Vous verrez que la plupart d'entre eux n'utilisent pas du tout de transactions, mais il existe d'énormes magasins en ligne qui les utilisent.

Answer 4

Bien sûr, cela dépend.

Cela dépend du travail effectué par la procédure stockée particulière et, peut-être, pas tant du "rapport lecture/écriture" que vous suggérez.En général, vous devriez envisager d’inclure une unité de travail dans une transaction s’il s’agit d’une requête qui pourrait être affectée par une autre requête exécutée simultanément.Si cela semble non déterministe, c’est effectivement le cas.Il est souvent difficile de prédire dans quelles circonstances une unité de travail particulière peut prétendre à cette qualification.

Un bon point de départ est de revoir les CRUD en cours d'exécution dans l'unité de travail, dans ce cas dans votre procédure stockée, et décidez si elle a) pourrait être affectée par une autre opération simultanée et b) si cet autre travail est important pour le résultat final de ce travail en cours d'exécution (ou , même vice versa).Si la réponse est « Oui » à ces deux questions, envisagez d'encapsuler l'unité de travail dans une transaction.

Ce que cela suggère, c'est que vous ne pouvez pas toujours simplement décider soit utiliser ou ne pas utiliser la transactions, vous devriez plutôt les appliquer lorsque cela a du sens.Utiliser les propriétés définies par ACIDE (Atomicité, Cohérence, Isolation et Durabilité) pour aider à décider quand cela pourrait être le cas.

Une autre chose à considérer est que dans certaines circonstances, en particulier si le système doit effectuer de nombreuses opérations en succession rapide, par exemple, une application de traitement de transactions à volume élevé, vous devrez peut-être peser le coût relatif des performances de la transaction.En fonction de la taille de l'unité de travail, une validation (ou une annulation) d'une transaction peut être coûteuse en ressources, pouvant avoir un impact négatif sur les performances de votre système inutilement ou, du moins, avec des avantages limités.

Malheureusement, il n’est pas facile de répondre précisément à cette question :"Ça dépend."

Answer 5

Utilisez-les si :

1. Il y a certaines erreurs que vous souhaiterez peut-être tester et détecter et qui ne seront détectées que si vous effectuez le travail (recherche de choses, test de valeurs, etc.), généralement à partir d'une transaction afin que vous puissiez lancer revenir sur toute l'opération.
2. Il existe des opérations en plusieurs étapes de toute sorte qui devraient, logiquement, être annulées en tant que groupe en cas d'échec.