Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Apprendre Atomicité | Acid
Techniques Avancées en SQL

bookAtomicité

Atomicité en SQL fait référence à l'une des propriétés ACID, qui garantit l'utilisation des transactions lors de l'interrogation des données avec SQL.
Dans le contexte des bases de données SQL, l'atomicité assure que toutes les opérations au sein d'une unité logique particulière sont réalisées, ou aucune d'entre elles ne l'est.

Traitement des transactions en SQL

Caractéristiques principales

  • Rollback : Si une partie échoue (par exemple, en raison d'une erreur ou d'une violation de contrainte), l'ensemble de la transaction est annulé, rétablissant les modifications ;

  • Commit : Si toutes les opérations réussissent, la transaction est validée, rendant les modifications permanentes.

Création de transactions en SQL

En SQL, chaque instruction individuelle est considérée comme une transaction.
Cependant, il est possible de créer manuellement des transactions contenant plusieurs instructions.

Imaginons un scénario avec deux tables :

  • la table BankAccounts, qui comprend les colonnes suivantes : account_number (Primary Key), account_holder et balance;

  • la table UserLogs avec les colonnes : account_number, action, timestamp etc. La combinaison de account_number et timestamp constitue une clé primaire composite de cette relation.

Considérons maintenant un scénario où l’on souhaite créer un nouveau compte bancaire et, simultanément, générer une entrée de journal pour signaler l’ajout de ce nouveau compte.
Il est impératif que ces deux actions, l’ajout du compte et la consignation de l’événement, soient traitées comme une seule unité logique et doivent être encapsulées dans une seule transaction. Voici un exemple très basique de la manière dont cela peut être réalisé avec une transaction :

-- Begin the transaction
BEGIN;

-- Insert a new bank account with account number 109, account holder Emma Watson, and initial balance of 0
INSERT INTO BankAccounts (account_number, account_holder, balance)
VALUES (109, 'Emma Watson', 0);

-- Step 2: Add log entry if the account was added
-- Insert a log entry into the UserLogs table indicating that a new account was added with account number 109
INSERT INTO UserLogs (account_number, action)
VALUES (109, 'New account added');

-- Commit the transaction, making the changes permanent
COMMIT;

Dans la requête ci-dessus, nous utilisons le bloc BEGIN pour indiquer que toutes les instructions suivantes doivent être considérées comme une seule unité : si l’une d’elles n’est pas exécutée, aucune des instructions ne doit l’être.
Le mot-clé COMMIT marque la fin du bloc de transaction.

question mark

Que garantit le concept d’atomicité dans le contexte des transactions de base de données ?

Select the correct answer

Tout était clair ?

Comment pouvons-nous l'améliorer ?

Merci pour vos commentaires !

Section 1. Chapitre 3

Demandez à l'IA

expand

Demandez à l'IA

ChatGPT

Posez n'importe quelle question ou essayez l'une des questions suggérées pour commencer notre discussion

Awesome!

Completion rate improved to 4.35

bookAtomicité

Glissez pour afficher le menu

Atomicité en SQL fait référence à l'une des propriétés ACID, qui garantit l'utilisation des transactions lors de l'interrogation des données avec SQL.
Dans le contexte des bases de données SQL, l'atomicité assure que toutes les opérations au sein d'une unité logique particulière sont réalisées, ou aucune d'entre elles ne l'est.

Traitement des transactions en SQL

Caractéristiques principales

  • Rollback : Si une partie échoue (par exemple, en raison d'une erreur ou d'une violation de contrainte), l'ensemble de la transaction est annulé, rétablissant les modifications ;

  • Commit : Si toutes les opérations réussissent, la transaction est validée, rendant les modifications permanentes.

Création de transactions en SQL

En SQL, chaque instruction individuelle est considérée comme une transaction.
Cependant, il est possible de créer manuellement des transactions contenant plusieurs instructions.

Imaginons un scénario avec deux tables :

  • la table BankAccounts, qui comprend les colonnes suivantes : account_number (Primary Key), account_holder et balance;

  • la table UserLogs avec les colonnes : account_number, action, timestamp etc. La combinaison de account_number et timestamp constitue une clé primaire composite de cette relation.

Considérons maintenant un scénario où l’on souhaite créer un nouveau compte bancaire et, simultanément, générer une entrée de journal pour signaler l’ajout de ce nouveau compte.
Il est impératif que ces deux actions, l’ajout du compte et la consignation de l’événement, soient traitées comme une seule unité logique et doivent être encapsulées dans une seule transaction. Voici un exemple très basique de la manière dont cela peut être réalisé avec une transaction :

-- Begin the transaction
BEGIN;

-- Insert a new bank account with account number 109, account holder Emma Watson, and initial balance of 0
INSERT INTO BankAccounts (account_number, account_holder, balance)
VALUES (109, 'Emma Watson', 0);

-- Step 2: Add log entry if the account was added
-- Insert a log entry into the UserLogs table indicating that a new account was added with account number 109
INSERT INTO UserLogs (account_number, action)
VALUES (109, 'New account added');

-- Commit the transaction, making the changes permanent
COMMIT;

Dans la requête ci-dessus, nous utilisons le bloc BEGIN pour indiquer que toutes les instructions suivantes doivent être considérées comme une seule unité : si l’une d’elles n’est pas exécutée, aucune des instructions ne doit l’être.
Le mot-clé COMMIT marque la fin du bloc de transaction.

question mark

Que garantit le concept d’atomicité dans le contexte des transactions de base de données ?

Select the correct answer

Tout était clair ?

Comment pouvons-nous l'améliorer ?

Merci pour vos commentaires !

Section 1. Chapitre 3
some-alt