Atomicité
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
etbalance
; -
la table
UserLogs
avec les colonnes :account_number
,action
,timestamp
etc. La combinaison deaccount_number
ettimestamp
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.
Merci pour vos commentaires !
Demandez à l'IA
Demandez à l'IA
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
Atomicité
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
etbalance
; -
la table
UserLogs
avec les colonnes :account_number
,action
,timestamp
etc. La combinaison deaccount_number
ettimestamp
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.
Merci pour vos commentaires !