Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Lære Atomisitet | Acid
Quizzes & Challenges
Quizzes
Challenges
/
SQL-optimalisering og spørringsfunksjoner

bookAtomisitet

Atomisitet i SQL refererer til en av ACID-egenskapene, som sikrer at vi bruker transaksjoner når vi forespør data med SQL.
I konteksten av SQL-databaser garanterer atomisitet at alle operasjoner innenfor en bestemt logisk enhet blir fullført, eller ingen av dem blir det.

Transaksjonsbehandling i SQL

Nøkkelfunksjoner

  • Tilbakerulling: Hvis noen del feiler (f.eks. på grunn av feil eller brudd på begrensninger), blir hele transaksjonen rullet tilbake, og endringer reverseres;

  • Commit: hvis alle operasjoner lykkes, blir transaksjonen bekreftet, og endringene blir permanente.

Opprettelse av transaksjoner i SQL

I SQL regnes hver individuell setning som en transaksjon.
Vi kan imidlertid manuelt opprette transaksjoner som inneholder mer enn én setning.

La oss tenke oss et scenario der vi har to tabeller:

  • tabellen BankAccounts, som inkluderer følgende kolonner: account_number (Primary Key), account_holder og balance;

  • UserLogs-tabellen med kolonner: account_number, action, timestamp osv. Kombinasjonen av account_number og timestamp er en sammensatt primærnøkkel for denne relasjonen.

I de neste kodeeksemplene vil du se hvordan data settes inn og håndteres i disse tabellene, og demonstrerer atomiske operasjoner ved bruk av reelle oppføringer fra det oppgitte skjemaet.

12
SELECT * FROM BankAccounts;
copy
12
SELECT * FROM UserLogs;
copy

La oss nå vurdere et scenario der det er ønskelig å opprette en ny bankkonto og samtidig generere en loggoppføring for å markere at den nye kontoen er lagt til.
Det er avgjørende at disse to handlingene, å legge til kontoen og loggføre hendelsen, behandles som én logisk enhet og må pakkes inn i én enkelt transaksjon. Her er et svært grunnleggende eksempel på hvordan dette kan gjøres med en transaksjon:

123456789101112131415161718
-- 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; -- Check the result SELECT * FROM BankAccounts; SELECT * FROM UserLogs;
copy

I spørringen ovenfor bruker vi BEGIN-blokken for å angi at alle påfølgende setninger må behandles som én enhet – hvis én av dem ikke blir utført, skal ingen av setningene utføres.
Nøkkelordet COMMIT markerer slutten på transaksjonsblokken.

question mark

Hva sikrer begrepet atomisitet i forbindelse med databasetransaksjoner?

Select the correct answer

Alt var klart?

Hvordan kan vi forbedre det?

Takk for tilbakemeldingene dine!

Seksjon 1. Kapittel 3

Spør AI

expand

Spør AI

ChatGPT

Spør om hva du vil, eller prøv ett av de foreslåtte spørsmålene for å starte chatten vår

bookAtomisitet

Sveip for å vise menyen

Atomisitet i SQL refererer til en av ACID-egenskapene, som sikrer at vi bruker transaksjoner når vi forespør data med SQL.
I konteksten av SQL-databaser garanterer atomisitet at alle operasjoner innenfor en bestemt logisk enhet blir fullført, eller ingen av dem blir det.

Transaksjonsbehandling i SQL

Nøkkelfunksjoner

  • Tilbakerulling: Hvis noen del feiler (f.eks. på grunn av feil eller brudd på begrensninger), blir hele transaksjonen rullet tilbake, og endringer reverseres;

  • Commit: hvis alle operasjoner lykkes, blir transaksjonen bekreftet, og endringene blir permanente.

Opprettelse av transaksjoner i SQL

I SQL regnes hver individuell setning som en transaksjon.
Vi kan imidlertid manuelt opprette transaksjoner som inneholder mer enn én setning.

La oss tenke oss et scenario der vi har to tabeller:

  • tabellen BankAccounts, som inkluderer følgende kolonner: account_number (Primary Key), account_holder og balance;

  • UserLogs-tabellen med kolonner: account_number, action, timestamp osv. Kombinasjonen av account_number og timestamp er en sammensatt primærnøkkel for denne relasjonen.

I de neste kodeeksemplene vil du se hvordan data settes inn og håndteres i disse tabellene, og demonstrerer atomiske operasjoner ved bruk av reelle oppføringer fra det oppgitte skjemaet.

12
SELECT * FROM BankAccounts;
copy
12
SELECT * FROM UserLogs;
copy

La oss nå vurdere et scenario der det er ønskelig å opprette en ny bankkonto og samtidig generere en loggoppføring for å markere at den nye kontoen er lagt til.
Det er avgjørende at disse to handlingene, å legge til kontoen og loggføre hendelsen, behandles som én logisk enhet og må pakkes inn i én enkelt transaksjon. Her er et svært grunnleggende eksempel på hvordan dette kan gjøres med en transaksjon:

123456789101112131415161718
-- 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; -- Check the result SELECT * FROM BankAccounts; SELECT * FROM UserLogs;
copy

I spørringen ovenfor bruker vi BEGIN-blokken for å angi at alle påfølgende setninger må behandles som én enhet – hvis én av dem ikke blir utført, skal ingen av setningene utføres.
Nøkkelordet COMMIT markerer slutten på transaksjonsblokken.

question mark

Hva sikrer begrepet atomisitet i forbindelse med databasetransaksjoner?

Select the correct answer

Alt var klart?

Hvordan kan vi forbedre det?

Takk for tilbakemeldingene dine!

Seksjon 1. Kapittel 3
some-alt