SQL är vårt allt

Som du säkert redan gissat kan alla kommandon till SQL-servern ges via SQL-frågor. Allt.

Dessa lag är officiellt indelade i 4 grupper:

  • datadefinitionssatser (Data Definition Language, DDL ) :

    • CREATE skapar ett databasobjekt (databasen själv, tabell, vy, användare och så vidare)
    • ALTER ändrar ett objekt
    • DROP tar bort ett objekt
  • datamanipuleringsoperatörer (Data Manipulation Language, DML ) :

    • SELECT väljer data som uppfyller givna villkor
    • INSERT lägger till ny data
    • UPPDATERING ändrar befintliga data
    • DELETE tar bort data
  • definitionsoperatörer för dataåtkomst (Data Control Language, DCL ):

    • GRANT ger en användare (grupp) behörighet att utföra vissa operationer på ett objekt
    • REVOKE återkallar tidigare utfärdade behörigheter
    • DENY sätter ett förbud som har företräde framför ett tillstånd
  • Transaction Control Language ( TCL ) uttalanden :

    • COMMIT tillämpar en transaktion
    • ROLLBACK rullar tillbaka alla ändringar som gjorts i samband med den aktuella transaktionen
    • SAVEPOINT delar upp en transaktion i mindre sektioner

Och de två första nivåerna studerade vi bara varianter av SELECT-satsen. Föreställ dig hur många intressanta saker som väntar oss i framtiden.

Men vi förbereder här främst om Java-programmerare, så vi kommer att studera de scenarier som du definitivt kommer att stöta på på jobbet.

Systemadministratören på projektet kommer med största sannolikhet att skapa alla databaser, men du kommer definitivt att behöva göra ett urval från data själv många gånger.

Dessutom, ibland kommer din kod inte att skriva all data till databasen eller skriva den på fel sätt, så du måste ofta klättra in i den med pennor och se vad som faktiskt finns lagrad där.

Låt oss gå igenom de saker vi berört i tidigare föreläsningar igen.

Skapa ett schema i en databas

För att skapa ett nytt schema i DBMS måste du köra kommandot:

CREATE SCHEMA Name;

Detta är det enklaste alternativet. När du skapar ett nytt schema kan du också ange datakodningsformatet och andra parametrar.

Om du vill ta bort schemat, men du är osäker på om det finns, måste du köra kommandot:

DROP SCHEMA IF EXIST Name;

Du kommer ofta att se dessa kommandon i filer med säkerhetskopior av olika databaser, det är därför jag tar med dem här.

Väljer det aktuella schemat

Om du har många scheman i ditt DBMS så kan det lätt hända att olika scheman har samma tabeller. För att undvika förvirring kan du göra två saker:

  • Sätt alltid schemanamnet före tabellnamnet
  • Ange standardschema

Låt oss skriva en fråga som väljer data från användartabellen , som finns i testschemat . Det kommer att se ut ungefär så här:

SELECT * FROM test.user;

Detta är helt enkelt oumbärligt om du behöver ansluta (JOIN) flera tabeller från olika scheman i en fråga.

Förresten, i Java-språket gör vi ofta något liknande: om vi i koden behöver använda klasser med samma namn från olika paket, lägger vi till paketnamnet före klassnamnet.

Det andra sättet är att ange standardschemat . Om frågan anger ett tabellnamn men inget schema, används standardschemat. För att göra detta, använd USE-satsen :

USE name - schemes;

Låt oss skriva om den tidigare frågan med USE-satsen:

USE test;
SELECT * FROM user;

Skapa en vy

Förutom tabeller med riktiga data, låter SQL dig lagra något som virtuella tabeller, där data hämtas från riktiga tabeller. Sådana virtuella tabeller kallas VIEW.

En sådan tabell kan inte lagra verklig data, och varje gång den nås drar den data från riktiga tabeller. Innehållet i en sådan VIEW specificeras med hjälp av en SQL-fråga.

Du kan skapa en VIEW från valfri SELECT-fråga med ett kommando som:

CREATE VIEW Name AS
SELECT-request;
Låt oss skriva en fråga som kommer att skapa en public_employee virtuell tabell baserad på tabellen för anställda, där information om anställdas lön kommer att döljas:
CREATE VIEW public_employee AS
SELECT id, name FROM employee

I exemplet ovan kommer vår tabell (VIEW) public_employee endast att innehålla anställdas ID och deras namn, men inte information om deras lön. Du kan använda sådana vyer på samma plats som riktiga bord.

Varför behövs visningar? De har ett antal fördelar:

Flexibel kontroll av tillgång till information . Du kan ge vissa användare åtkomst endast till VIEW, men inte för att ge åtkomst till tabeller. Och i View, ta endast ut offentlig information från tabeller. Dessutom, om nya kolumner med viktig information läggs till i tabellerna i framtiden, kommer den inte av misstag att hamna i vyn.

Datadenormalisering . För att underlätta lagringen delas data ofta upp i hundratals och tusentals tabeller, men det är inte särskilt bekvämt för en vanlig person att arbeta med sådan data - du måste skriva för komplexa frågor. Med View kan du skapa virtuella tabeller som visar data från dussintals olika tabeller i en enda tabell.

Polymorfism och inkapsling . Du kan ändra strukturerna i din databas. Samtidigt kommer användare av programmet som arbetar med dina vyer inte att gissa att något har förändrats. Och det kommer inte att finnas något behov av att skriva om koden för program som har tillgång till View. Du behöver bara justera SQL-skriptet som är relaterat till VIEW.

Endast läs . View kan bara ställas in med en SELECT-fråga, så att arbeta med View kan inte ändra data i verkliga tabeller på något sätt. Förresten, detta är ytterligare ett plus till förmån för query caching. Men mer om det nästa gång.