Lucrul cu SQL Server

SQL este totul pentru noi

După cum probabil ghiciți deja, toate comenzile către serverul SQL pot fi date prin interogări SQL. Tot.

Aceste echipe sunt împărțite oficial în 4 grupe:

• declarații de definire a datelor (Data Definition Language, DDL ):

  • CREATE creează un obiect de bază de date (baza de date însăși, tabel, vizualizare, utilizator și așa mai departe)
  • ALTER schimbă un obiect
  • DROP elimină un obiect

• operatori de manipulare a datelor (Data Manipulation Language, DML ):

  • SELECT selectează datele care îndeplinesc condițiile date
  • INSERT adaugă date noi
  • UPDATE modifică datele existente
  • DELETE elimină datele

• operatori de definire a accesului la date (Data Control Language, DCL ):

  • GRANT acordă unui utilizator (grup) permisiuni pentru a efectua anumite operații asupra unui obiect
  • REVOKE revocă permisiunile emise anterior
  • DENY stabilește o interdicție care are prioritate față de un permis

• Instrucțiuni TCL ( Transaction Control Language) :

  • COMMIT aplică o tranzacție
  • ROLLBACK derulează înapoi toate modificările făcute în contextul tranzacției curente
  • SAVEPOINT împarte o tranzacție în secțiuni mai mici

Iar primele două niveluri, am studiat doar varietăți ale instrucțiunii SELECT. Imaginează-ți câte lucruri interesante ne așteaptă în viitor.

Dar ne pregătim aici în primul rând despre programatorii Java, așa că vom studia acele scenarii pe care cu siguranță le vei întâlni la locul de muncă.

Administratorul de sistem al proiectului va crea cel mai probabil toate bazele de date, dar cu siguranță va trebui să faceți singur o selecție din datele de mai multe ori.

Mai mult, uneori, codul tău nu va scrie toate datele în baza de date sau le va scrie în mod greșit, așa că va trebui adesea să te urci în el cu pixuri și să vezi ce este de fapt stocat acolo.

Să trecem din nou peste lucrurile pe care le-am atins în prelegerile anterioare.

Crearea unei scheme într-o bază de date

Pentru a crea o nouă schemă în DBMS, trebuie să rulați comanda:

CREATE SCHEMA Name;

Aceasta este cea mai ușoară opțiune. De asemenea, atunci când creați o nouă schemă, puteți specifica formatul de codificare a datelor și alți parametri.

Dacă doriți să ștergeți schema, dar nu sunteți sigur dacă există, atunci trebuie să rulați comanda:

DROP SCHEMA IF EXIST Name;

Veți vedea adesea aceste comenzi în fișiere cu copii de siguranță ale diferitelor baze de date, de aceea le aduc aici.

Selectarea schemei curente

Dacă aveți o mulțime de scheme în SGBD, atunci se poate întâmpla cu ușurință ca diferite scheme să aibă aceleași tabele. Pentru a evita confuzia, puteți face două lucruri:

• Pune întotdeauna numele schemei înaintea numelui tabelului
• Specificați schema implicită

Să scriem o interogare care va selecta date din tabelul utilizator , care se află în schema de testare . Va arata cam asa:

SELECT * FROM test.user;

Acest lucru este pur și simplu indispensabil dacă trebuie să alăturați (JOIN) mai multe tabele din scheme diferite într-o singură interogare.

Apropo, în limbajul Java facem adesea ceva similar: dacă în cod trebuie să folosim clase cu același nume din pachete diferite, adăugăm numele pachetului înaintea numelui clasei.

A doua modalitate este de a specifica schema implicită . Dacă interogarea specifică un nume de tabel, dar nicio schemă, se utilizează schema implicită. Pentru a face acest lucru, utilizați instrucțiunea USE :

USE name - schemes;

Să rescriem interogarea anterioară folosind instrucțiunea USE:

USE test;
SELECT * FROM user;

Crearea unei vizualizări

Pe lângă tabelele cu date reale, SQL vă permite să stocați ceva de genul tabelelor virtuale, unde datele sunt extrase din tabele reale. Astfel de tabele virtuale se numesc VIEW.

Un astfel de tabel nu poate stoca date reale și, de fiecare dată când este accesat, extrage date din tabele reale. Conținutul unei astfel de VIEW este specificat folosind o interogare SQL.

Puteți crea o vizualizare din orice interogare SELECT cu o comandă ca:

CREATE VIEW Name AS
SELECT-request;

CREATE VIEW public_employee AS
SELECT id, name FROM employee

În exemplul de mai sus, tabelul nostru (VIEW) public_employee va conține doar ID-urile angajaților și numele acestora, dar nu informații despre salariul lor. Puteți utiliza astfel de vizualizări în același loc ca și tabele reale.

De ce sunt necesare Vizualizări? Au o serie de avantaje:

Control flexibil al accesului la informații . Puteți acorda anumitor utilizatori acces doar la VIEW, dar nu și pentru a acorda acces la tabele. Și în View, scoateți numai informații publice din tabele. În plus, dacă în viitor sunt adăugate noi coloane cu informații importante în tabele, acestea nu vor intra accidental în vizualizare.

Denormalizarea datelor . Pentru comoditatea stocării, datele sunt adesea împărțite în sute și mii de tabele, dar nu este foarte convenabil pentru o persoană obișnuită să lucreze cu astfel de date - trebuie să scrieți interogări prea complexe. Cu View, puteți crea tabele virtuale care afișează date din zeci de tabele diferite într-un singur tabel.

Polimorfism și încapsulare . Puteți modifica structurile bazei de date. În același timp, utilizatorii programului care lucrează cu vizualizările dvs. nu vor ghici că ceva s-a schimbat. Și nu va fi nevoie să rescrieți codul programelor care au acces la View. Va trebui doar să modificați scriptul SQL care este legat de VIEW.

Numai citit . Vizualizarea poate fi setată numai cu o interogare SELECT, astfel încât lucrul cu View nu poate modifica în niciun fel datele din tabelele reale. Apropo, acesta este un alt plus în favoarea stocării în cache a interogărilor. Dar mai multe despre asta data viitoare.