Jobber med SQL Server

SQL er vårt alt

Som du sikkert allerede har gjettet, kan alle kommandoer til SQL-serveren gis gjennom SQL-spørringer. Alt.

Disse lagene er offisielt delt inn i 4 grupper:

• datadefinisjonssetninger (Data Definition Language, DDL ) :

  • CREATE oppretter et databaseobjekt (selve databasen, tabell, visning, bruker og så videre)
  • ALTER endrer et objekt
  • DROP fjerner et objekt

• datamanipulasjonsoperatører (Data Manipulation Language, DML ) :

  • SELECT velger data som tilfredsstiller gitte betingelser
  • INSERT legger til nye data
  • OPPDATERING endrer eksisterende data
  • SLETT fjerner data

• definisjonsoperatører for datatilgang (Data Control Language, DCL ):

  • GRANT gir en bruker (gruppe) tillatelser til å utføre visse operasjoner på et objekt
  • REVOKE tilbakekaller tidligere utstedte tillatelser
  • DENY setter et forbud som går foran en tillatelse

• Transaction Control Language ( TCL ) uttalelser :

  • COMMIT bruker en transaksjon
  • ROLLBACK ruller tilbake alle endringer som er gjort i sammenheng med gjeldende transaksjon
  • SAVEPOINT deler en transaksjon i mindre seksjoner

Og de to første nivåene studerte vi bare varianter av SELECT-setningen. Tenk hvor mange interessante ting som venter oss i fremtiden.

Men vi forbereder oss her først og fremst om Java-programmerere, så vi vil studere scenariene du definitivt vil møte på jobben.

Systemadministratoren på prosjektet vil mest sannsynlig lage alle databasene, men du må definitivt gjøre et utvalg fra dataene selv mange ganger.

Dessuten vil noen ganger ikke koden din skrive all data til databasen eller skrive den på feil måte, så du må ofte klatre inn i den med penner og se hva som faktisk er lagret der.

La oss gå gjennom tingene vi har vært inne på i tidligere forelesninger på nytt.

Opprette et skjema i en database

For å lage et nytt skjema i DBMS må du kjøre kommandoen:

CREATE SCHEMA Name;

Dette er det enkleste alternativet. Når du oppretter et nytt skjema, kan du også spesifisere datakodingsformatet og andre parametere.

Hvis du vil slette skjemaet, men du er usikker på om det eksisterer, må du kjøre kommandoen:

DROP SCHEMA IF EXIST Name;

Du vil ofte se disse kommandoene i filer med sikkerhetskopier av forskjellige databaser, det er derfor jeg bringer dem her.

Velge gjeldende skjema

Hvis du har mange skjemaer i DBMS, så kan det lett skje at forskjellige skjemaer har de samme tabellene. For å unngå forvirring kan du gjøre to ting:

• Sett alltid skjemanavnet foran tabellnavnet
• Angi standardskjema

La oss skrive en spørring som vil velge data fra brukertabellen , som er i testskjemaet . Det vil se omtrent slik ut:

SELECT * FROM test.user;

Dette er ganske enkelt uunnværlig hvis du trenger å slå sammen (BLI MED) flere tabeller fra forskjellige skjemaer i en spørring.

Forresten, i Java-språket gjør vi ofte noe lignende: hvis vi i koden må bruke klasser med samme navn fra forskjellige pakker, legger vi til pakkenavnet før klassenavnet.

Den andre måten er å spesifisere standardskjemaet . Hvis spørringen spesifiserer et tabellnavn, men ikke noe skjema, brukes standardskjemaet. For å gjøre dette, bruk USE-setningen :

USE name - schemes;

La oss omskrive den forrige spørringen ved å bruke USE-setningen:

USE test;
SELECT * FROM user;

Opprette en visning

I tillegg til tabeller med ekte data, lar SQL deg lagre noe som virtuelle tabeller, hvor data hentes fra ekte tabeller. Slike virtuelle tabeller kalles VIEW.

En slik tabell kan ikke lagre ekte data, og hver gang den åpnes, henter den data fra virkelige tabeller. Innholdet i en slik VIEW spesifiseres ved hjelp av en SQL-spørring.

Du kan opprette en VIEW fra en hvilken som helst SELECT-spørring med en kommando som:

CREATE VIEW Name AS
SELECT-request;

CREATE VIEW public_employee AS
SELECT id, name FROM employee

I eksemplet ovenfor vil vår tabell (VIEW) public_employee bare inneholde medarbeider-IDer og deres navn, men ikke informasjon om lønnen deres. Du kan bruke slike visninger på samme sted som ekte bord.

Hvorfor trengs visninger? De har en rekke fordeler:

Fleksibel kontroll over tilgang til informasjon . Du kan gi enkelte brukere tilgang kun til VIEW, men ikke til å gi tilgang til tabeller. Og i View, ta bare ut offentlig informasjon fra tabeller. I tillegg, hvis nye kolonner med viktig informasjon legges til tabellene i fremtiden, vil den ikke ved et uhell komme inn i visningen.

Data denormalisering . For enkelhets skyld er data ofte delt inn i hundrevis og tusenvis av tabeller, men det er ikke veldig praktisk for en vanlig person å jobbe med slike data - du må skrive for komplekse spørringer. Med View kan du lage virtuelle tabeller som viser data fra dusinvis av forskjellige tabeller i en enkelt tabell.

Polymorfisme og innkapsling . Du kan endre strukturene i databasen. Samtidig vil ikke brukere av programmet som jobber med dine Views gjette at noe har endret seg. Og det vil ikke være nødvendig å omskrive koden til programmer som har tilgang til View. Du trenger bare å justere SQL-skriptet som er relatert til VIEW.

Kun lesetilgang . View kan bare settes med en SELECT-spørring, så arbeid med View kan ikke endre dataene i virkelige tabeller på noen måte. Forresten, dette er et annet pluss til fordel for spørringsbufring. Men mer om det neste gang.