MySQL Utför ACID -transaktioner och referensintegritet

Varje applikation som innehåller en databas måste överensstämma med ACID -egenskaper, i applikationerna och professionella databashanterare avser ACID -konceptet egenskaper eller egenskaper som garanterar att transaktionerna i databaserna utförs säkert och konfidensiellt. Specifikt står ACID för atomicitet, konsistens, isolering och hållbarhet.

En transaktion i en databas är till exempel att infoga en post eller, om vi ser det som en affärsmodell, Lägg till ny kund, Ändra produkt. Transaktioner producerar alltid en ändring, infogar, ändrar, tar bort, en fråga är inte en transaktion eftersom den inte producerar ändringar.
Ange syraegenskaper

Atomicitet

Det är egenskapen som garanterar och verifierar om transaktionen genomfördes eller inte och den här egenskapen indikerar att om en operation inte utförs slutför den att den avbryts, till exempel anta att vi sätter in en post och servern kraschar, en post är inspelad i mitten, då på grund av atomicitet kommer denna post inte att spelas in.
Ett annat exempel om en online -betalning görs och beloppet dras från vårt konto men betalningen misslyckas eller systemet kraschar, avbryts transaktionen och databasen registrerar det inte.

Konsistens

Det är fastigheten som garanterar att transaktioner som kan slutföras utan problem kommer att genomföras. Detta koncept har att göra med databasens integritet. Det förhindrar att data ändras och förlorar mening eller är utan någon referens, till exempel kan en kund inte raderas medan de har gjort ett köp någon gång. Om du vill radera kunden måste du först ta bort alla fakturor och data som är relaterade till den kunden.

Isolering

Det är egenskapen som garanterar att om två eller flera transaktioner sker samtidigt kommer de att köras en efter en och om de utförs parallellt kommer var och en att göra det oberoende av den andra för att undvika eventuella fel.

Varaktighet

Det är fastigheten som är ansvarig för att garantera att en transaktion har gjorts och de ändringar som görs av transaktionen är permanenta, även om det uppstår problem som brist på el eller systemfel.
MySQL stöder InnoDB -formatet, som är en form av datalagring för MySQL, som ingår som ett standardtabellformat i alla MySQL -distributioner. Detta format stöder transaktioner av typen ACID och referensintegritet.
Vi ska göra några exempel på ACID -implementering med Mysql, frågorna kan sedan implementeras på valfritt programmeringsspråk. I denna databas kommer varje användare att ha en nivå av privilegier och åtgärder som de kan utföra i företagets system. Vi kommer bara att fokusera på den funktionen.
Vi börjar med att skapa en databas Företag DB från phpmyadmin, då ska vi skapa en användartabell och välja InnoDB -lagringsmotor.

 - Tabellstruktur för tabell `användare` SKAPA TABELL OM DET INTE ÄR FÖRFINANDE` användare` (` userid` int (10) NOT NULL, `name` varchar (150) DEFAULT NULL) MOTOR = InnoDB AUTO_INCREMENT = 4 DEFAULT CHARSET = latin1;

Vi lägger till lite data i användartabellen

 INSERT INTO `users` (` userid`, `name`) VÄRDEN (1, 'Carlos Alberte'), (2, 'Pablo Callejos'), (3, 'Ana Bolena');

I det här fallet skapar vi huvudnyckeln för användartabellen som kommer att vara userid

 - Index över tabellen `användare` ALTER TABLE` användare` ADD PRIMARY KEY (` userid`);

Därefter skapar vi nivåtabellen

 - Tabellstruktur för tabell `nivåer` SKAPA TABELL OM DET INTE FÖRESKRIVAS` nivåer` (`levelid` int (11) NOT NULL,` level` varchar (50) DEFAULT NULL) MOTOR = InnoDB AUTO_INCREMENT = 4 DEFAULT CHARSET = latin1;

Vi lägger till lite data i tabellen nivåer

 SÄTT IN I 'nivåer' ('levelid', 'level') VÄRDEN (1, 'Basic'), (2, 'Intermediate'), (3, 'Advanced');

Vi skapar sedan privilegietabellen, där vi kommer att ange behörighetsnivån för varje användare

 - Tabellstruktur för tabell `privilegier` SKAPA TABELL OM INTE FÖRESKRIVS` privilegier` (` idprivilege` int (11) NOT NULL, `idlevel` int (11) NOT NULL DEFAULT '0', 'idusuario' int (11) NOT NULL ) ENGINE = InnoDB AUTO_INCREMENT = 4 DEFAULT CHARSET = latin1;

Vi lägger till lite data i privilegietabellen

 INSERT INTO `privilegies` (` privilegeid`, `levelid`,` userid`) VÄRDEN (1, 1, 1), (2, 2, 3), (3, 1, 2);

Vi lägger sedan till relationerna från SQL -editoren, jag tilldelar en främmande nyckel som relaterar privilegierna och användartabellen genom användar -id och den utländska nyckeln som relaterar privilegier med nivåer genom nivå -id.

 - Filter för tabellen `privilegier` ALTER TABLE` privilegier` ADD CONSTRAINT` levellfk` FOREIGN KEY (`levelid`) REFERENCES` levels` (`levelid`), ADD CONSTRAINT` privilegesfk` FOREIGN KEY (`userid`) REFERENCES` användare `('userid');

Därefter konsulterar vi databasen för att se om data är korrekta

 VÄLJ användare.namn, levels.level FRÅN användare, nivåer, privilegier VAR privilegier.idlevel = levels.levelid ANDusers.userid = privileges.userid

Låt oss se hur det fungerar nästa vi försöker infoga privilegierna till en användare och nivå som inte finns.
Uttalandet kommer att vara följande INSERT INTO privilegies VALUES (privilegeid, userid, levelid); Således

 SÄTT IN I privilegier VÄRDEN (6, 8,10);

Detta ger ett fel eftersom den främmande nyckeln för userid i privilegietabellen skulle skapa en inkonsekvens om vi lägger till en användare som inte finns i användartabellen, här undviker vi felet, med formatet MySam data skulle ha sparats utan problem.
Därefter försöker vi ta bort en användare från användartabellen:

 DELETE FROM `users` WHERE userid = 3

När vi kör SQL -satsen kommer det att ge oss ett fel eftersom klienten inte kan raderas eftersom den har data i andra tabeller i det här fallet klienten med id 3 finns i privilegietabellen, om vi vill ta bort den måste vi först ta bort den från alla bord och efter kundbordet.

För att radera denna typ av poster med främmande nycklar används den som kallas ta bort i Vattenfall, där alla poster relaterade till en viss fråga kommer att raderas i alla tabeller där de har främmande nyckelrelationer. För att genomföra denna transaktion använder vi funktionen PÅ RADERA CASCADE.
Det första är att ge behörighet att radera i kaskad, kom ihåg att referenstypen är som standard BEGRÄNSA vilket indikerar att data i det fältet i tabellen inte kan uppdateras eller raderas, detta är av säkerhetsskäl, varje mening som utförs kommer inte att kunna utföra någon transaktion, så vi ändrar modifierings- och raderingstillstånden.

 ALTER TABLE `privilegies` ADD CONSTRAINT` privilegesfk` FOREIGN KEY (` userid`) REFERENCES` users` (`userid`) ON DELETE CASCADE ON UPDATE CASCADE;

Vi utför SQL -frågan igen

 DELETE FROM `users` WHERE userid = 3

Sedan kan vi utföra sql -frågan för att verifiera att den inte längre finns i någon tabell:

 VÄLJ användarnamn, nivåer.nivå FRÅN användare, nivåer, privilegier VAR privilegier.idlevel = levels.idlevel OCH users.userid = privileges.userid

Användare 3 har tagits bort från användartabellen och från privilegietabellen, eftersom userid hade en utländsk nyckel där.
Detta är samma sak för uppdateringar vid ändring, det kan kaskad för att upprätthålla referensintegritet i Mysql och förhållandet mellan tabeller.
Låt oss se vad som händer om vi lägger till felaktiga data i kedjan, till exempel lägger vi till en användare, men när vi lägger till rättigheter får vi fel id

 INSERT INTO users VALUES (5, 'Julia Montaña'); INSERT INTO privilegies (`privilegeid`,` levelid`, `userid`) VÄRDEN (6, 2, 6);

I det här fallet sparas användaren men inte deras privilegier eftersom ID 6 inte finns i användartabellen.Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng