Dev Faq
10
votes

Dois-je utiliser des transactions SQL, tout en lisant des enregistrements?

Les transactions SQL sont utilisées pour insertion, mise à jour, mais doivent-elles être utilisées pour la lecture des enregistrements?

1 commentaires

Merci à tous les répondeurs, j'aimerais qu'il y ait la possibilité de marquer tout comme des réponses mais il n'y a pas. Merci d'avoir donné des exemples, pour donner un lien vers l'explication du verrouillage, pour expliquer comment obtenir des données à jour en millisecondes, merci.

7 Réponses :

3
votes

L'emballage de transaction n'est pas nécessaire pour des lectures pures.

Dans votre relevé SQL, les indications de verrouillage doivent prendre soin de vous renvoyer des données appropriées ( http://msdn.microsoft.com/en-us/library/aa213026%28SQL.80%29.aspx ). P>

sur un niveau de serveur, vous pouvez définir des niveaux d'isolation de transaction ( http://msdn.microsoft.com/en-us/library/ms173763.cox ). P>

Modifier strong> p>

Exploiter pur lit p>

si tout votre instruction SQL a ce type de lecture, vous n'avez pas besoin d'envelopper une transaction p> xxx pré>

si vous lisez des résultats qui peuvent être affecté par d'autres transactions en parallèle, vous devez envelopper une transaction. EG: P> 

BEGIN TRANSACTION

INSERT INTO AccountTransactions (Type, Amount) Values ('Credit', 43.21)
UPDATE AccountSummary SET Balance = Balance + 43.21

SELECT @Balance = Balance FROM AccountSummary

COMMIT TRANSACTION

7 commentaires

Dans l'exemple suivant, tout processus simultané pourrait interférer avec les tables que vous lisez. Il n'y a pas d'écriture de données, mais il y a des calculs entre des lectures connexes. En tant que telle transaction, il serait nécessaire de protéger l'état des données. Insérer dans @temp sélectionnez ; ; Sélectionnez ;

Ce n'est pas une lecture pure cependant. Raj a déclaré que "l'emballage de transaction n'est pas nécessaire pour des lectures pures".

Définir "PURE Lecture", l'exemple que j'ai donné n'inquiète, met à jour ni ne supprime à autre chose qu'une variable. [Il pourrait s'agir d'une carte INT, d'une variable de table ou d'un autre conteneur de données pour faciliter les calculs qui définiront ensuite le comportement de la lecture finale]

Vous modifiez les appels de structure @temp. C'est une déclaration d'insertion, pas une lecture pure, surtout si votre @temp est utilisé dans la déclaration Selet Déclaration qui suit.

Mais d'une billet noire, rien dans la base de données n'a changé. Par exemple, les variables TEMP peuvent être utilisées dans des fonctions définies par l'utilisateur. Par votre définition de "PURE Lecture", vous ne pouvez même pas utiliser des variables int, et, en tant que tel, je vous soutiendrais, vous êtes limité à une seule déclaration SQL. Je dirais que "la lecture pure" décrit en fait un processus qui ne provoque aucune modification (temporaire ou permanente) de la base de données ou de son contenu, être visible ou non à un autre processus. Dans mon esprit, n'exigeant que même des variables sont utilisées décrivent un scénario trop trivial.

Votre exemple de Supprimer de

où in (sous-requête) est toujours lié dans une transaction implicite car elle constitue une seule instruction SQL. La liaison dans une transaction n'aurait aucun effet.

@Dems, vous avez raison en ce qu'il n'y a pas de séparation entre le Select et le Supprimer. Je vais corriger ça.

2
votes

Si vous avez besoin de la plupart des informations sur les informations millisecondes, vous pouvez utiliser une transaction construite avec une transaction transactionOPtion ayant un isolationlevel de sérialisable . .

Cela effectuerait la performance car elle verrouille la table (ou des parties de la table) afin de déterminer si vous avez vraiment besoin de cela.

Pour la plupart des utilisations, si vous faites une lecture, vous n'avez pas besoin d'envelopper une transaction autour de celle-ci (en supposant que vous ne faites que des lectures dans la seule opération).

Cela dépend vraiment de votre application, quelles données nécessitent et comment elle l'utilise.

Par exemple, si vous faites une lecture et en fonction des résultats que vous effectuez une écriture ou une mise à jour, mais il est essentiel que les données que vous venez de lire sont à jour, vous devez probablement envelopper la logique entière dans une seule transaction.

0 commentaires
8
votes

Si vous interrogez tous les enregistrements dans une seule requête et que vous les retirez en une fois, il n'y a pas besoin. Tout est enveloppé dans une transaction implicite. C'est-à-dire que même si vous récupérez un million d'enregistrements, et même si d'autres processus changent les enregistrements, vous verrez quels million d'enregistrements ressemblaient au même moment.

Les seules fois que vous auriez vraiment besoin d'une transaction (et, souvent, d'un indice de verrouillage spécifique) dans un processus en lecture seule sont:
- Vous lisez les enregistrements "Pièce-Repas" et vous n'avez besoin de rien d'autre pour modifier les valeurs pendant que vous idiots. [Tels qu'un jeu d'enregistrement connecté à ADO que vous faites curseur.]
- Vous lisez certaines données, faites quelques calculs, puis lisez certaines données associées, mais sur l'hypothèse, rien n'a changé dans la période moyenne.


En bref, vous avez besoin de transactions lorsque vous souhaitez que d'autres processus soient arrêtés d'interférer avec vos données entre les instructions SQL.

0 commentaires
1
votes

Non, les transactions ne sont généralement pas nécessaires pour lire les données et ralentiront également vos données de données.

Je vous suggérerais de lire sur le terme atomique. Cela vous aidera à comprendre quelles transactions sont destinées.

0 commentaires
1
votes

Il est possible de faire des transactions, mais ce qui y est fait?

Vous pouvez définir le niveau d'isolement approprié pour une session de serveur SQL complète à l'aide de l'instruction de niveau d'isolement de la transaction définie. P>

Ceci est la syntaxe de SQL Server Books Online: P> 

SET TRANSACTION ISOLATION LEVEL 
    {
        READ COMMITTED 
        | READ UNCOMMITTED 
        | REPEATABLE READ 
        | SERIALIZABLE
    }

0 commentaires
0
votes

Lorsque vous avez modifié quelque chose dans une transaction, vous pouvez utiliser la déclaration de lecture pour vérifier si l'opération prend effet, juste avant de vous engager.

0 commentaires
0
votes

Les transactions sont censées éviter les problèmes de concurrence lorsqu'une transaction logique correspond à plusieurs requêtes SQL. Par exemple, pour un compte bancaire, si vous transférez de l'argent d'un compte à un autre, vous soustrayez le montant du compte de compte, puis de l'ajouter à d'autres (ou inversement). Mais si une erreur se produit entre votre base de données serait dans un état non valide (vous avez peut-être soustrait le montant d'un compte, mais pas l'a ajouté à d'autres). Donc, si vous lisez toutes vos données dans une requête, vous n'avez pas besoin d'une transaction.

0 commentaires

Articles qui pourrait vous intéresser :

Calculer la différence dans l'échelle d'évaluation alphabétique
Ignorer la propriété de l'interface utilisateur Swagger
Comment détruire les éléments dynamiques du panneau dans le script Unity C #
Entity Framework Core 3.1 avec NetTopologySuite.Geometries.Point: SqlException: la valeur fournie n'est pas une instance valide de la géographie du type de données