Devrait-il y avoir une transaction pour les requêtes lues?

Question

J'ai lu que certains devs / dbas recommandaient d'utiliser des transactions dans tous les appels de base de données, même les appels en lecture seule. Bien que je comprenne l'insertion / la mise à jour dans une transaction, quel est l'avantage de la lecture dans une transaction?

Answer 1

Vous obtenez ainsi une vue cohérente de la base de données. Imaginez que vous ayez deux tables qui se lient l'une à l'autre, mais pour une raison quelconque, vous faites 2 sélections ... en pseuodocode:

myRows = query(SELECT * FROM A)
moreRows = query(SELECT * FROM B WHERE a_id IN myRows[id])

Si, entre les deux requêtes, quelqu'un modifie B pour supprimer certaines lignes, vous rencontrez un problème.

Answer 2

Semblable à ce que RoBorg a dit, vous feriez SÉLECTIONNER des transactions avec i pour empêcher la lecture de données fantômes entre les instructions. MAIS , il est important de noter que le niveau d'isolation de transaction par défaut dans SQL Server est READ COMMITTED, ce qui empêche uniquement les lectures modifiées. Pour éviter les données fantômes, vous devez utiliser au moins REPEATABLE READ. "Utilisez cette option uniquement lorsque cela est nécessaire."

http://msdn.microsoft.com/en-us/library /ms173763.aspx

Answer 3

J'ai constaté que les "transactions" se comportaient très différemment sur différents serveurs SQL. Dans certains cas, le démarrage d'une transaction empêche toutes les autres connexions d'exécuter un SQL jusqu'à ce que la transaction soit validée ou annulée (MS SQLServer 6.5). D'autres n'ont aucun problème et ne se verrouillent que lorsqu'il y a une modification (oracle). Les verrous peuvent même s’étendre pour n’englober que vos modifications: verrous à cellules / verrous de ligne / verrous de page / verrous de table.

En règle générale, j'utilise des transactions uniquement lorsque l'intégrité des données entre plusieurs instructions d'insertion / suppression / mise à jour doit être conservée. Même quand même, je préfère implémenter cela en utilisant des suppressions en cascade définies par la base de données pour que la base de données le fasse automatiquement et de manière atomique.

Utilisez une transaction si vous pouvez prévoir une situation dans laquelle vous voudriez annuler plusieurs modifications, mais dans le cas contraire, la base de données effectuera ses mises à jour atomiques sans le code supplémentaire pour y faire face.

Answer 4

Je vérifie cela depuis quelques minutes, car je devrais en savoir plus. Voici ce que j'ai trouvé.

Les transactions seraient utiles autour d'un select si vous souhaitez verrouiller cette ligne pendant qu'une personne lit des enregistrements et ne souhaite pas qu'elle soit modifiée ou lue. Par exemple, exécutez ces requêtes:

(dans la fenêtre de requête 1)

COMMENCER TRAN SÉLECTIONNEZ * À PARTIR DE MYTABLE AVEC (ROWLOCK XLOCK) O ID = 1

(dans la fenêtre de requête 2)

SELECT * FROM MYTABLE O ID = 1

(la fenêtre de requête 2 ne renverra pas de résultats tant que vous ne l'utiliserez pas dans la fenêtre 1)

COMMIT TRAN

Liens utiles:

http://msdn.microsoft.com/en-us/library /aa213039.aspx

http://msdn.microsoft.com/en-us/library /aa213026.aspx

http://msdn.microsoft.com/en-us/library /ms190345.aspx

Mon objectif était d’obtenir quelque chose à bloquer - et cela a finalement fonctionné après l’ajout du XLOCK. Simplement utiliser ROWLOCK ne fonctionnait pas. Je suppose qu’il s’agissait d’un verrou partagé (et les données avaient été lues) .. mais je suis toujours en train d’explorer cela.

Ajouter - AVEC (UPDLOCK ROWLOCK) - vous permettra de sélectionner et de verrouiller les lignes pour les mises à jour, ce qui faciliterait la concurrence.

Soyez prudent avec les astuces sur les tableaux. Si vous commencez à les appliquer au hasard, votre système ralentira au ralenti si vous ne recevez même qu'un petit nombre d'utilisateurs sur votre application. C’est la seule chose que je savais avant d’examiner cette question;)

Answer 5

Je dirais que l’un des principaux objectifs d’une transaction est d’offrir un potentiel de retour en arrière s’il ya des problèmes - ce qui n’est plus d'actualité lors de la lecture.