Illustrert selvstudieguide til SQL for nybegynnere. Kategoriarkiver: Bøker om SQL sql-programmeringsspråket for dummies

Fra forfatteren: Har du blitt kalt en tekanne? Vel, dette kan fikses! Hver samovar var en gang en tekanne! Eller var alle profesjonelle en gang en samovar? Nei, igjen er det noe galt! Alt i alt er MySQL for nybegynnere.

Hvorfor dummies trenger MySQL

Hvis du seriøst skal koble livet ditt med Internett, vil du ved de aller første trinnene i "nettet" komme over denne DBMS. MySQL kan trygt kalles "all Internet" databasebehandlingssystemet. Ikke en eneste mer eller mindre seriøs ressurs kan klare seg uten den, den finnes i adminpanelet til hver hosting. Og mest av alt er populære CMS og til og med selvlagde motorer bygget med hennes deltakelse.

Generelt kan du ikke klare deg uten denne plattformen. Men for å studere det trenger du også den riktige tilnærmingen, de riktige verktøyene, og viktigst av alt, lyst og tålmodighet. Jeg håper du har nok av det siste. Og vær forberedt på at hjernen din vil koke, og dampen faller ut av hodet ditt, som fra en ekte tekanne

Men MySQL er så vanskelig for dummies bare hvis du begynner å lære det feil. Vi vil ikke gjøre en slik feil, og vi vil begynne å bli kjent med denne teknologien helt fra begynnelsen.

Enkle konsepter

Først, la oss gå gjennom de grunnleggende konseptene som vi vil nevne i dette innlegget:

Database (DB) er den viktigste konstituerende enheten i DBMS. Databasen inneholder tabeller som består av kolonner og poster (rader). Cellene som dannes i krysset inneholder strukturerte data av en bestemt type.

DBMS (database management system) - et sett med alle programvaremoduler for databaseadministrasjon.

SQL er et strukturert spørrespråk, ved hjelp av hvilket utvikleren "kommuniserer" med kjernen (serveren) i DBMS. Som alle programmeringsspråk har SQL sin egen syntaks, sett med kommandoer og operatører, støttede datatyper.

Jeg tror vi har nok teoretisk kunnskap til å begynne med. Vi vil "male" de manglende hullene i teori med praksis. Nå gjenstår det bare å velge riktig programvareverktøy.

Finne riktig verktøy

Etter å ha "rotet" ganske mye i hele utvalget av MySQL-skall for nybegynnere, innså jeg at disse rett og slett ikke eksisterer. Alle programvareprodukter for DBMS-administrasjon krever en allerede installert databaseserver. Generelt bestemte jeg meg nok en gang for ikke å finne opp "scooteren", og valgte den innenlandske Denwer-pakken. Du kan laste den ned på den offisielle nettsiden.

Den inkluderer allerede alle komponentene i DBMS, slik at en nybegynner kan begynne praktisk bekjentskap med MySQL rett etter en enkel og forståelig installasjon. I tillegg inkluderer Denwer flere andre verktøy som er nødvendige for en nybegynner: lokal server, PHP.

Første steg

Jeg vil ikke beskrive installasjonsprosessen til "gentlemen's"-settet, siden alt skjer automatisk der. Etter å ha startet installasjonen, har du bare tid til å trykke på de nødvendige tastene. Akkurat det du trenger i dummy-versjonen av MySQL.

Når installasjonsprosessen er over, start den lokale serveren, vent et par sekunder. Etter det skriver du localhost i adressefeltet i nettleseren din.

På siden "Hurra, det funker!" følg en av lenkene på bildet. Deretter vil du bli tatt til phpMyAdmin - et skall for databaseadministrasjon.

Ved å klikke på lenken http://downloads.mysql.com/docs/world.sql.zip, vil du laste ned en prøvedatabase fra det offisielle MySQL-nettstedet. Gå til phpMyAdmin igjen, i hovedmenyen øverst gå til fanen "Importer". I vinduet "Importer til gjeldende" i den første delen ("Fil som skal importeres"), sett verdien "Bla gjennom datamaskinen".

I utforskervinduet velger du arkivet med den nedlastede eksempeldatabasen. Ikke glem å klikke "Ok" nederst i hovedvinduet.

Jeg anbefaler deg å ikke endre de angitte parameterverdiene for nå. Dette kan føre til feil visning av dataene til den importerte kilden. Hvis phpMyAdmin gir en feilmelding om at den ikke kan gjenkjenne databasekomprimeringsalgoritmen, pakk den ut og gjenta hele importprosessen fra begynnelsen.

Hvis alt gikk bra, vil programmeldingen vises øverst om at importen var vellykket, og til venstre i DB-listen er det et annet (ord).

La oss se på strukturen fra innsiden slik at du klarere kan forestille deg hva du må forholde deg til.

Klikk på navnet til MySQL Database for Beginners. En liste over tabeller den består av vil vises under den. Klikk på en av dem. Gå deretter til toppmenyen "Struktur". Hovedarbeidsområdet viser strukturen til tabellen: alle kolonnenavn, datatyper og alle attributter.

Denne opplæringen er noe sånt som et "stempel av minnet mitt" for SQL-språket (DDL, DML), dvs. dette er informasjon som har akkumulert i løpet av min yrkesaktivitet og som stadig er lagret i hodet mitt. Dette er et tilstrekkelig minimum for meg, som brukes oftest når jeg jobber med databaser. Hvis det blir nødvendig å bruke mer komplette SQL-konstruksjoner, henvender jeg meg vanligvis til MSDN-biblioteket på Internett for å få hjelp. Etter min mening er det veldig vanskelig å holde alt i hodet, og det er ikke noe særlig behov for dette. Men det er veldig nyttig å kjenne til de grunnleggende konstruksjonene, fordi de kan brukes i nesten samme form i mange relasjonsdatabaser som Oracle, MySQL, Firebird. Forskjellene er hovedsakelig i datatyper, som kan variere i detalj. Det er ikke så mange grunnleggende konstruksjoner av SQL-språket, og med konstant øvelse huskes de raskt. For å lage objekter (tabeller, begrensninger, indekser osv.), er det for eksempel nok å ha en tekstredigerer for miljøet (IDE) for hånden for å jobbe med databasen, og det er ikke nødvendig å studere visuelle verktøy som er skjerpet for arbeider med en bestemt type database (MS SQL, Oracle, MySQL, Firebird, ...). Det er også praktisk fordi all teksten er foran øynene dine, og du trenger ikke å gå gjennom mange faner for å lage for eksempel en indeks eller en begrensning. Med konstant arbeid med en database er det mange ganger raskere å lage, endre og spesielt gjenskape et objekt ved hjelp av skript enn om det gjøres i visuell modus. Også i skriptmodus (følgelig, med tilbørlig forsiktighet) er det lettere å sette og kontrollere reglene for navngivning av objekter (min subjektive mening). I tillegg er skript praktiske å bruke når endringer gjort i en database (for eksempel en test) må overføres i samme form til en annen (produktiv) database.

SQL-språket er delt inn i flere deler, her vil jeg diskutere de 2 viktigste delene av det:

• DML - Data Manipulation Language, som inneholder følgende konstruksjoner:
  • SELECT - datavalg
  • INSERT - setter inn nye data
  • OPPDATERING - dataoppdatering
  • SLETT - sletter data
  • SLUTNING - datasammenslåing

Fordi Jeg er en praktiker, det vil være lite teori som sådan i denne opplæringen, og alle konstruksjoner vil bli forklart med praktiske eksempler. I tillegg tror jeg at et programmeringsspråk, og spesielt SQL, kun kan mestres i praksis, ved at du selv føler det og forstår hva som skjer når du utfører den eller den konstruksjonen.

Denne opplæringen er basert på Step by Step-prinsippet, dvs. det er nødvendig å lese den sekvensielt og helst umiddelbart etter eksemplene. Men hvis du underveis har behov for å lære mer om en kommando mer detaljert, så bruk et spesifikt søk på Internett, for eksempel i MSDN-biblioteket.

Når jeg skrev denne opplæringen, ble MS SQL Server-databaseversjonen 2014 brukt, for å utføre skriptene jeg brukte MS SQL Server Management Studio (SSMS).

Kort om MS SQL Server Management Studio (SSMS)

SQL Server Management Studio (SSMS) er et verktøy for Microsoft SQL Server for å konfigurere, administrere og administrere databasekomponenter. Dette verktøyet inneholder en script editor (som vi hovedsakelig skal bruke) og et grafisk program som fungerer med serverobjekter og innstillinger. Hovedverktøyet i SQL Server Management Studio er Object Explorer, som lar brukeren se, hente og manipulere serverobjekter. Denne teksten er delvis lånt fra Wikipedia.

For å opprette et nytt skriptredigeringsprogram, bruk Ny spørring-knappen:

For å endre gjeldende database kan du bruke nedtrekkslisten:

For å utføre en spesifikk kommando (eller en gruppe kommandoer), velg den og trykk på Utfør-knappen eller F5-tasten. Hvis det bare er én kommando i editoren for øyeblikket, eller du trenger å utføre alle kommandoer, trenger du ikke velge noe.

Etter å ha utført skript, spesielt de som oppretter objekter (tabeller, kolonner, indekser), for å se endringene, bruk oppdateringen fra kontekstmenyen ved å velge riktig gruppe (for eksempel tabeller), selve tabellen eller kolonnegruppen i den.

Faktisk er dette alt vi trenger å vite for å utføre eksemplene gitt her. Resten av SSMS-verktøyet er enkelt å lære på egen hånd.

Litt teori

En relasjonsdatabase (RDB, eller videre i sammenheng med bare en database) er en samling tabeller som er sammenkoblet. Grovt sett er en database en fil der data lagres i en strukturert form.

DBMS er et styringssystem for disse databasene, dvs. det er et sett med verktøy for å jobbe med en bestemt type database (MS SQL, Oracle, MySQL, Firebird, ...).

Merk
Fordi i livet, i dagligtale, sier vi for det meste: "Oracle DB", eller til og med bare "Oracle", som faktisk betyr "Oracle DBMS", så i sammenheng med denne opplæringen vil begrepet DB noen ganger bli brukt. Ut fra konteksten tror jeg det vil fremgå hva det dreier seg om.

En tabell er en samling av kolonner. Kolonner kan også kalles felt eller kolonner, alle disse ordene vil bli brukt synonymt for å uttrykke det samme.

Tabellen er hovedobjektet til RDB, alle RDB-data lagres linje for linje i kolonnene i tabellen. Strenger, poster er også synonymer.

For hver tabell, så vel som for dens kolonner, er det gitt navn, som de deretter får tilgang til.
Et objektnavn (tabellnavn, kolonnenavn, indeksnavn osv.) i MS SQL kan ha en maksimal lengde på 128 tegn.

For referanse- i ORACLE-databasen kan objektnavn ha en maksimal lengde på 30 tegn. Derfor, for en spesifikk database, må du utvikle dine egne regler for navngivning av objekter for å holde deg innenfor grensen for antall tegn.

SQL er et språk som lar deg utføre spørringer i en database ved hjelp av en DBMS. I et spesifikt DBMS kan SQL-språket ha en spesifikk implementering (sin egen dialekt).

DDL og DML er en undergruppe av SQL-språket:

• DDL-språket brukes til å lage og endre databasestrukturen, dvs. for å opprette / endre / slette tabeller og lenker.
• DML-språk tillater manipulering av tabelldata, dvs. med replikkene hennes. Den lar deg velge data fra tabeller, legge til nye data i tabeller og oppdatere og slette eksisterende data.

Det er 2 typer kommentarer som kan brukes i SQL (enkeltlinje og flerlinje):

Enkeltlinjekommentar
og

/ * kommentar med flere linjer * /

Egentlig vil dette være nok for teorien.

DDL - Data Definition Language

Tenk for eksempel på en tabell med data om ansatte, i vanlig form for en person som ikke er programmerer:

I dette tilfellet har kolonnene i tabellen følgende navn: Personalnummer, fullt navn, Fødselsdato, E-post, Stilling, Avdeling.

Hver av disse kolonnene kan karakteriseres av typen data den inneholder:

• Personalnummer - heltall
• Fullt navn - streng
• Fødselsdato - dato
• E-post - streng
• Posisjon - streng
• Avdeling - streng

Kolonnetype er en egenskap som indikerer hva slags data en gitt kolonne kan lagre.

Til å begynne med vil det være nok å huske bare følgende grunnleggende datatyper som brukes i MS SQL:

Betydning	MS SQL notasjon	Beskrivelse
Variabel lengde streng	varchar (N) og nvarchar (N)	Med tallet N kan vi spesifisere maksimal mulig radlengde for den tilsvarende kolonnen. For eksempel, hvis vi vil si at verdien av "navn"-kolonnen kan inneholde maksimalt 30 tegn, må vi sette den til typen nvarchar (30). Forskjellen mellom varchar og nvarchar er at varchar lagrer strenger i ASCII-format, hvor ett tegn er 1 byte, mens nvarchar lagrer strenger i Unicode-format, hvor hvert tegn er 2 byte. Varchar-typen skal kun brukes hvis du er 100 % sikker på at feltet ikke trenger å lagre Unicode-tegn. For eksempel kan varchar brukes til å lagre e-postadresser fordi de inneholder vanligvis bare ASCII-tegn.
Fast lengde streng	røye (N) og nchar (N)	Denne typen skiller seg fra en streng med variabel lengde ved at hvis strengen er mindre enn N tegn lang, så er den alltid polstret til høyre til lengden på N med mellomrom og lagret i databasen i denne formen, dvs. den opptar nøyaktig N tegn i databasen (hvor ett tegn opptar 1 byte for char og 2 byte for nchar). I min praksis brukes denne typen svært sjelden, og hvis den brukes, så brukes den hovedsakelig i char (1)-formatet, dvs. når feltet er definert av ett tegn.
Heltall	int	Denne typen lar oss bruke bare heltall i kolonnen, både positive og negative. For referanse (nå er dette ikke så relevant for oss) - rekkevidden av tall som int-typen tillater er fra -2 147 483 648 til 2 147 483 647. Vanligvis er dette hovedtypen som brukes til å sette identifikatorer.
Reelt eller reelt tall	flyte	Enkelt sagt er dette tall der et desimaltegn (komma) kan være til stede.
Dato	Dato	Hvis du bare trenger å lagre Dato i kolonnen, som består av tre komponenter: Antall, Måned og År. For eksempel 15.02.2014 (15. februar 2014). Denne typen kan brukes for kolonnen "Opptaksdato", "Fødselsdato" osv. i tilfeller der det er viktig for oss å fikse kun datoen, eller når tidskomponenten ikke er viktig for oss og kan forkastes eller hvis den ikke er kjent.
Tid	tid	Denne typen kan brukes hvis kun tidsdata skal lagres i en kolonne, dvs. Timer, minutter, sekunder og millisekunder. For eksempel 17:38: 31.3231603 For eksempel den daglige "Flight Departure Time".
dato og tid	dato tid	Denne typen lar deg lagre både dato og klokkeslett samtidig. For eksempel, 15.02.2014 17:38: 31.323 Dette kan for eksempel være dato og klokkeslett for en hendelse.
Flagg	bit	Denne typen er praktisk for å lagre verdier som "Ja" / "Nei", der "Ja" vil bli lagret som 1, og "Nei" vil bli lagret som 0.

Feltverdien, hvis den ikke er forbudt, kan heller ikke spesifiseres, for dette formålet brukes nøkkelordet NULL.

For å kjøre eksemplene, la oss lage en testbase kalt Test.

En enkel database (uten å spesifisere flere parametere) kan opprettes ved å kjøre følgende kommando:

LAG DATABASE Test
Du kan slette databasen med kommandoen (du bør være veldig forsiktig med denne kommandoen):

DROP DATABASE Test
For å bytte til databasen vår kan du kjøre kommandoen:

BRUK Test
Alternativt kan du velge Testdatabasen fra rullegardinlisten i SSMS-menyområdet. Når jeg jobber bruker jeg ofte denne metoden for å bytte mellom baser.

Nå i databasen vår kan vi lage en tabell ved å bruke beskrivelsene slik de er, med mellomrom og kyrilliske tegn:

LAG TABELL [Ansatte] ([Personalnummer] int, [Fullt navn] nvarchar (30), [Fødselsdato] dato, nvarchar (30), [Posisjon] nvarchar (30), [Avdeling] nvarchar (30))
I dette tilfellet må vi sette navnene i hakeparenteser [...].

Men i databasen, for større bekvemmelighet, er det bedre å spesifisere alle navn på objekter i det latinske alfabetet og ikke bruke mellomrom i navnene. I MS SQL, vanligvis i dette tilfellet, begynner hvert ord med stor bokstav, for eksempel for feltet "Personnelnummer" kan vi angi navnet PersonnelNumber. Du kan også bruke numre i navnet, for eksempel PhoneNumber1.

På en lapp
I noen DBMS kan følgende navneformat "PHONE_NUMBER" være mer å foretrekke, for eksempel brukes dette formatet ofte i ORACLE DB. Når du spesifiserer feltnavnet, er det naturligvis ønskelig at det ikke sammenfaller med nøkkelordene som brukes i DBMS.

Av denne grunn kan du glemme syntaksen for hakeparenteser og slette tabellen [Ansatte]:

DROP TABELL [Ansatte]
For eksempel kan en tabell med ansatte hete "Ansatte", og feltene kan navngis som følger:

• ID – Personalnummer (medarbeider-ID)
• Navn - fullt navn
• Fødselsdag - fødselsdato
• E-post - E-post
• Posisjon – Posisjon
• Avdeling - Avdeling

Svært ofte brukes ordet ID for å navngi identifikasjonsfeltet.

La oss nå lage tabellen vår:

LAG TABELL Ansatte (ID int, Navn nvarchar (30), Bursdagsdato, E-post nvarchar (30), Stilling nvarchar (30), Avdeling nvarchar (30))
Du kan bruke NOT NULL-alternativet for å spesifisere nødvendige kolonner.

For en eksisterende tabell kan feltene omdefineres ved hjelp av følgende kommandoer:

Oppdatering av ID-feltet ALTER TABLE Ansatte ALTER COLUMN ID int NOT NULL - oppdatering av Name-feltet ALTER TABLE Ansatte ALTER COLUMN Navn nvarchar (30) NOT NULL

På en lapp
Det generelle konseptet for SQL-språket for de fleste DBMS-er forblir det samme (i det minste kan jeg bedømme dette ut fra DBMS-ene jeg har jobbet med). Forskjellen mellom DDL i forskjellige DBMS-er ligger hovedsakelig i datatyper (her kan ikke bare navnene deres variere, men også detaljene i implementeringen), spesifikasjonene for implementeringen av SQL-språket kan også avvike litt (dvs. essensen av kommandoene er de samme, men det kan være små forskjeller i dialekten, dessverre, men det er ingen standard). Når du kjenner til det grunnleggende om SQL, kan du enkelt bytte fra ett DBMS til et annet, fordi i dette tilfellet trenger du bare å forstå detaljene i implementeringen av kommandoer i det nye DBMS, dvs. i de fleste tilfeller vil en enkel analogi være tilstrekkelig.

Opprett tabell LAG TABELL Ansatte (ID int, - i ORACLE, int type er ekvivalenten (wrapper) for nummer (38) Navn nvarchar2 (30), - nvarchar2 i ORACLE tilsvarer nvarchar i MS SQL Bursdagsdato, E-post nvarchar2 (30) ) , Stilling nvarchar2 (30), Avdeling nvarchar2 (30)); - oppdatering av ID- og Name-feltene (her MODIFY (...) brukes i stedet for ALTER COLUMN) ALTER TABLE Ansatte MODIFY (ID int NOT NULL, Name nvarchar2 (30) NOT NULL); - legge til PK (i dette tilfellet ser konstruksjonen ut som i MS SQL, den vil bli vist nedenfor) ALTER TABLE Ansatte ADD CONSTRAINT PK_Employees PRIMARY KEY (ID);
For ORACLE er det forskjeller når det gjelder implementering av varchar2-typen, kodingen avhenger av databaseinnstillingene og teksten kan lagres, for eksempel i UTF-8-koding. I tillegg kan feltlengden i ORACLE settes både i byte og i tegn, for dette brukes tilleggsalternativer BYTE og CHAR, som er spesifisert etter feltlengden, for eksempel:

NAME varchar2 (30 BYTE) - feltkapasiteten vil være 30 byte NAME varchar2 (30 CHAR) - feltkapasiteten vil være 30 tegn
Hvilket alternativ som vil bli brukt som standard BYTE eller CHAR, i tilfelle av en enkel indikasjon av typen varchar2 (30) i ORACLE, avhenger av databaseinnstillingene, det kan også noen ganger settes i IDE-innstillingene. Generelt kan det noen ganger være lett å bli forvirret, derfor, når det gjelder ORACLE, hvis varchar2-typen brukes (og dette er noen ganger begrunnet her, for eksempel når du bruker UTF-8-koding), foretrekker jeg å eksplisitt skrive CHAR (siden det vanligvis er mer praktisk å lese strenglengden i tegn ).

Men i dette tilfellet, hvis tabellen allerede inneholder noen data, er det nødvendig å fylle ut ID- og Navn-feltene i alle rader i tabellen for vellykket utførelse av kommandoene. La oss demonstrere dette med et eksempel, sett inn data i tabellen i ID, Posisjon og Avdeling-feltene, dette kan gjøres med følgende script:

INSERT Ansatte (ID, Stilling, Avdeling) VERDIER (1000, N "Direktor", N "Administrasjon"), (1001, N "Programmer", N "IT"), (1002, N "Regnskapsfører", N "Regnskap" ), (1003, N "Senior Programmer", N "IT")
I dette tilfellet vil INSERT-kommandoen også generere en feil, siden da vi satte inn, spesifiserte vi ikke verdien til det nødvendige Navn-feltet.
Hvis vi allerede hadde disse dataene i den opprinnelige tabellen, ville kommandoen "ALTER TABLE Employees ALTER COLUMN ID int NOT NULL" ha fullført vellykket, og kommandoen "ALTER TABLE Employees ALTER COLUMN Name int NOT NULL" ville ha generert en feilmelding , at det er NULL (uspesifisert) verdier i Navn-feltet.

Legg til verdier for Navn-feltet og fyll ut dataene på nytt:

Alternativet IKKE NULL kan også brukes direkte når du oppretter en ny tabell, dvs. i sammenheng med CREATE TABLE-kommandoen.

Først, la oss slette tabellen ved å bruke kommandoen:

DROP TABLE Ansatte
La oss nå lage en tabell med obligatoriske kolonner ID og Navn:

LAG TABELL Ansatte (ID int NOT NULL, Navn nvarchar (30) NOT NULL, Bursdagsdato, E-post nvarchar (30), Stilling nvarchar (30), Department nvarchar (30))
Du kan også skrive NULL etter navnet på kolonnen, noe som betyr at NULL-verdier (ikke spesifisert) vil være tillatt i den, men dette er ikke nødvendig, siden denne egenskapen antas som standard.

Hvis det tvert imot er nødvendig å gjøre den eksisterende kolonnen valgfri for fylling, bruker vi følgende kommandosyntaks:

ENDRINGSTABELL Ansatte ENDRE KOLONNE Navn nvarchar (30) NULL
Eller ganske enkelt:

ENDRINGSTABELL Ansatte ENDRE KOLONNE Navn nvarchar (30)
Med denne kommandoen kan vi også endre feltets type til en annen kompatibel type, eller endre lengden. La oss for eksempel utvide feltet Navn til 50 tegn:

ENDRE TABELL Ansatte ENDRE KOLONNE Navn nvarchar (50)

Primærnøkkel

Når du oppretter en tabell, er det ønskelig at den har en unik kolonne eller et sett med kolonner som er unikt for hver av dens rader - en post kan identifiseres unikt med denne unike verdien. Denne verdien kalles primærnøkkelen til tabellen. For vår Ansatte-tabell kan en slik unik verdi være ID-kolonnen (som inneholder "Ansattes personellnummer" - selv om denne verdien i vårt tilfelle er unik for hver ansatt og ikke kan gjentas).

Du kan opprette en primærnøkkel til en eksisterende tabell ved å bruke kommandoen:

ENDRINGSTABELL Ansatte ADD CONSTRAINT PK_Employees PRIMÆR NØKKEL (ID)
Hvor "PK_Employees" er navnet på begrensningen som er ansvarlig for primærnøkkelen. Vanligvis brukes "PK_"-prefikset til å navngi primærnøkkelen, etterfulgt av tabellnavnet.

Hvis primærnøkkelen består av flere felt, må disse feltene være oppført i parentes, atskilt med komma:

ALTER TABLE tabellnavn LEGG TIL BEGRENSNING begrensningsnavn PRIMÆR NØKKEL (felt1, felt2, ...)
Det er verdt å merke seg at i MS SQL må alle felt som er inkludert i primærnøkkelen IKKE være NULL.

Primærnøkkelen kan også defineres direkte når du oppretter tabellen, dvs. i sammenheng med CREATE TABLE-kommandoen. La oss slette tabellen:

DROP TABLE Ansatte
Og la oss lage den ved å bruke følgende syntaks:

LAG TABELL Ansatte (ID int NOT NULL, Navn nvarchar (30) NOT NULL, Bursdagsdato, E-post nvarchar (30), Stilling nvarchar (30), Avdeling nvarchar (30), BEGRENSNING PK_Employees PRIMÆR NØKKEL (ID) - beskriv tross alt PK felt som en begrensning)
Etter opprettelsen fyller du inn dataene i tabellen:

INSERT Ansatte (ID, Stilling, Avdeling, Navn) VERDIER (1000, N "Direktor", N "Administrasjon", N "Ivanov I.I."), (1001, N "Programmer", N "IT", N " Petrov PP " ), (1002, N" Regnskapsfører ", N" Regnskap ", N" Sidorov SS "), (1003, N" Senior programmerer ", N" IT ", N" Andreev A. A.")
Hvis primærnøkkelen i tabellen kun består av verdiene til én kolonne, kan følgende syntaks brukes:

LAG TABELL Ansatte (ID int NOT NULL CONSTRAINT PK_Employees PRIMARY KEY, - spesifiser som en egenskap for feltet Navn nvarchar (30) NOT NULL, Fødselsdato, E-post nvarchar (30), Stilling nvarchar (30), Avdeling nvarchar (30))
Faktisk trenger ikke navnet på begrensningen å angis, i så fall vil den bli tildelt et systemnavn (som "PK__Employee__3214EC278DA42077"):

LAG TABELL Ansatte (ID int NOT NULL, Navn nvarchar (30) NOT NULL, Bursdagsdato, E-post nvarchar (30), Stilling nvarchar (30), Department nvarchar (30), PRIMÆR NØKKEL (ID))
Eller:

LAG TABELL Ansatte (ID int NOT NULL PRIMÆR NØKKEL, Navn nvarchar (30) NOT NULL, Bursdagsdato, E-post nvarchar (30), Stilling nvarchar (30), Avdeling nvarchar (30))
Men jeg vil anbefale å alltid spesifisere begrensningsnavnet for vedvarende tabeller, siden med et eksplisitt gitt og forståelig navn, vil det senere være lettere å manipulere det, for eksempel kan du slette det:

ENDRINGSTABELL Ansatte SLIP BEGRENSNING PK_Ansatte
Men en så kort syntaks, uten å spesifisere navn på restriksjoner, er praktisk å bruke når du oppretter midlertidige databasetabeller (navnet på den midlertidige tabellen begynner med # eller ##), som vil bli slettet etter bruk.

La oss oppsummere

Så langt har vi dekket følgende kommandoer:

• LAG BORD tabellnavn (oppregning av felt og deres typer, begrensninger) - brukes til å lage en ny tabell i gjeldende database;
• DROPPE BORD tabellnavn - tjener til å slette en tabell fra gjeldende database;
• ENDRE TABELL tabellnavn ENDRE KOLONNE kolonnenavn... - brukes til å oppdatere typen til en kolonne eller endre dens innstillinger (for eksempel for å spesifisere NULL eller NOT NULL-karakteristikken);
• ENDRE TABELL tabellnavn LEGG TIL BEGRENSNING constraint_name PRIMÆRNØKKEL(felt1, felt2, ...) - legge til en primærnøkkel til en eksisterende tabell;
• ENDRE TABELL tabellnavn DROPPSBEGRENSNING constraint_name - fjerner begrensningen fra tabellen.

Litt om midlertidige bord

Utdrag fra MSDN. Det er to typer midlertidige tabeller i MS SQL Server: lokal (#) og global (##). Lokale midlertidige tabeller er kun synlige for skaperne til tilkoblingen til SQL Server-forekomsten avsluttes, så snart de først er opprettet. Lokale midlertidige tabeller blir automatisk slettet etter at en bruker kobler fra en forekomst av SQL Server. Globale midlertidige tabeller er synlige for alle brukere under alle tilkoblingsøkter etter at disse tabellene er opprettet, og slettes når alle brukere som refererer til disse tabellene kobler fra SQL Server-forekomsten.

Midlertidige tabeller opprettes i tempdb-systemdatabasen, dvs. ved å lage dem, forsøpler vi ikke hovedbasen, ellers er de midlertidige tabellene helt identiske med vanlige tabeller, de kan også droppes ved å bruke DROP TABLE-kommandoen. Lokale (#) midlertidige tabeller er mer vanlig å bruke.

Du kan bruke CREATE TABLE-kommandoen til å lage en midlertidig tabell:

LAG TABELL #Temp (ID int, Navn nvarchar (30))
Siden en midlertidig tabell i MS SQL ligner på en vanlig tabell, kan du også slippe den selv med kommandoen DROP TABLE:

SLIPP TABELL #Temp

Dessuten kan en midlertidig tabell (som en vanlig tabell selv) opprettes og umiddelbart fylles med data som returneres av en spørring ved å bruke SELECT ... INTO-syntaksen:

VELG ID, Navn INTO #Temp FRA ansatte

På en lapp
Implementering av midlertidige tabeller kan variere i forskjellige DBMS-er. For eksempel, i ORACLE og Firebird DBMS, må strukturen til midlertidige tabeller defineres på forhånd med CREATE GLOBAL TEMPORARY TABLE-kommandoen som indikerer spesifikasjonene for lagring av data i den, deretter ser brukeren den blant hovedtabellene og arbeider med den som med et vanlig bord.

Databasenormalisering - oppdeling i undertabeller (referansebøker) og definere relasjoner

Vår nåværende Ansatte-tabell har den ulempen at brukeren kan skrive inn hvilken som helst tekst i Stillings- og Avdelingsfeltene, noe som i utgangspunktet er beheftet med feil, siden en ansatt ganske enkelt kan spesifisere "IT" som avdeling, og en annen ansatt, for for eksempel, skriv inn "IT-avdeling", ved den tredje "IT". Som følge av dette vil det være uklart hva brukeren mente, d.v.s. Er disse ansatte ansatte ved samme avdeling, eller er brukeren beskrevet selv og dette er 3 forskjellige avdelinger? Dessuten vil vi i dette tilfellet ikke være i stand til å gruppere dataene riktig for en rapport, der det kan være nødvendig å vise antall ansatte i sammenheng med hver avdeling.

Den andre ulempen er mengden lagring av denne informasjonen og dens duplisering, dvs. for hver ansatt angis fullt navn på avdelingen, noe som krever plass i databasen for å lagre hvert tegn fra avdelingsnavnet.

Den tredje ulempen er kompleksiteten ved å oppdatere disse feltene hvis navnet på en stilling endres, for eksempel hvis du trenger å gi nytt navn til stillingen "Programmer" til "Junior Programmer". I dette tilfellet må vi gjøre endringer på hver linje i tabellen, der posisjonen er lik "Programmer".

For å unngå disse manglene, brukes den såkalte normaliseringen av databasen - deler den opp i undertabeller, referansetabeller. Det er ikke nødvendig å gå inn i teorijungelen og studere hva normale former er, det er nok å forstå essensen av normalisering.

La oss lage 2 tabeller "Posisjoner" og "Avdelinger", den første vil hete stillinger, og den andre, henholdsvis avdelinger:

CREATE TABLE Posisjoner (ID int IDENTITY (1,1) IKKE NULL BEGRENSNING PK_Positions PRIMARY KEY, Name nvarchar (30) NOT NULL) CREATE TABLE Avdelinger (ID int IDENTITY (1,1) IKKE NULL BEGRENSNING PK_Departments PRIMARY KEY, (30Navn NULL) ) IKKE NULL)
Merk at vi her har brukt det nye IDENTITY-alternativet, som sier at dataene i ID-kolonnen vil nummereres automatisk, fra 1, med et trinn på 1, dvs. når du legger til nye poster, vil de sekvensielt bli tildelt verdiene 1, 2, 3, etc. Slike felt blir ofte referert til som auto-inkrementering. Bare ett felt med IDENTITY-egenskapen kan defineres i en tabell, og vanligvis, men ikke nødvendigvis, er et slikt felt primærnøkkelen for den tabellen.

På en lapp
I ulike DBMS-er kan implementering av felt med teller gjøres på hver sin måte. I MySQL, for eksempel, er et slikt felt definert ved å bruke AUTO_INCREMENT-alternativet. I ORACLE og Firebird tidligere kunne denne funksjonaliteten emuleres ved å bruke SEQUENCE. Men så vidt jeg vet har ORACLE nå lagt til alternativet GENERERT SOM IDENTITET.

La oss fylle disse tabellene automatisk basert på gjeldende data registrert i Stillings- og Avdeling-feltene i tabellen Ansatte:

Fyll ut Navn-feltet i Stillingstabellen med unike verdier fra Stillingsfeltet i Ansatte-tabellen SETT INN stillinger (Navn) VELG DISTINKT posisjon FRA ansatte HVOR stillingen IKKE ER NULL - forkast poster hvis posisjon ikke er spesifisert
La oss gjøre det samme for avdelingstabellen:

SETT INN avdelinger (navn) VELG DISTINKT avdeling FRA ansatte HVOR avdeling IKKE ER NULL
Hvis vi nå åpner tabellene for stillinger og avdelinger, vil vi se et nummerert sett med verdier for ID-feltet:

VELG * FRA posisjoner

VELG * FRA avdelinger

Disse tabellene vil nå spille rollen som oppslagsverk for tildeling av stillinger og avdelinger. Vi vil nå referere til jobb- og avdelings-ID. Først av alt, la oss lage nye felt i tabellen Ansatte for å lagre identifikasjonsdataene:

Legg til et felt for stillingen ID ALTER TABLE Ansatte ADD PositionID int - legg til et felt for IDen til avdelingen ALTER TABLE Ansatte ADD DepartmentID int
Type referansefelt skal være den samme som i referansene, i dette tilfellet er det int.

Du kan også legge til flere felt i tabellen samtidig med én kommando, og liste opp feltene atskilt med kommaer:

ENDRINGSTABELL Ansatte ADD PositionID int, DepartmentID int
Nå vil vi skrive lenker (referansebegrensninger - FOREIGN KEY) for disse feltene slik at brukeren ikke kan skrive i disse feltene verdiene som er fraværende blant ID-verdiene som finnes i oppslagsbøkene.

ALTER TABLE Ansatte ADD CONSTRAINT FK_Employees_PositionID UTENLANDSKE NØKKEL (PosisjonsID) REFERANSER Stillinger (ID)
Og vi vil gjøre det samme for det andre feltet:

ALTER TABLE Ansatte ADD CONSTRAINT FK_Employees_DepartmentID UTENLANDSKE NØKKEL (DepartmentID) REFERANSER Avdelinger (ID)
Nå vil brukeren kun kunne legge inn ID-verdier fra den tilsvarende katalogen i disse feltene. Følgelig, for å bruke en ny avdeling eller stilling, må han først legge til en ny post i den tilsvarende katalogen. Fordi stillinger og avdelinger er nå lagret i kataloger i én enkelt kopi, så for å endre navnet er det nok å endre det bare i katalogen.

Navnet på referansebegrensningen er vanligvis en sammensatt, den består av prefikset "FK_", deretter følger navnet på tabellen, og etter understreken er det navnet på feltet som refererer til identifikatoren til referansetabellen.

Identifikatoren (ID) er vanligvis en intern verdi som kun brukes for lenker og hvilken verdi som er lagret der er i de fleste tilfeller helt likegyldig, så du trenger ikke å prøve å bli kvitt hull i tallrekkefølgen som oppstår under arbeidet med tabellen, for eksempel etter sletting av poster fra oppslagsboken.

ALTER TABLE-tabell ADD CONSTRAINT constraint_name UTENLANDSKE NØKKEL (felt1, felt2, ...) REFERANSER referansetabell (felt1, felt2, ...)
I dette tilfellet, i tabellen "dir_table", er primærnøkkelen representert av en kombinasjon av flere felt (felt1, felt2, ...).

La oss faktisk oppdatere PositionID og DepartmentID-feltene med ID-verdiene fra katalogene. La oss bruke DML UPDATE-kommandoen til dette formålet:

OPPDATERING e SET PositionID = (VELG ID FRA Stillinger WHERE Name = e.Position), AvdelingsID = (VELG ID FRA Avdelinger WHERE Name = e.Department) FRA Ansatte e
La oss se hva som skjedde ved å kjøre spørringen:

VELG * FRA Ansatte

Det er det, StillingsID- og Avdelings-ID-feltene fylles ut tilsvarende stillingene og avdelingene med identifikatorer, det er ikke behov for Stillings- og Avdelingsfeltene i tabellen Ansatte, du kan slette disse feltene:

ENDRINGSTABELL Ansatte SLIPPER KOLONNE Stilling, avdeling
Nå har tabellen fått følgende form:

VELG * FRA Ansatte

ID	Navn	Fødselsdag	E-post	Posisjons-ID	Avdelings-ID
1000	Ivanov I.I.	NULL	NULL	2	1
1001	Petrov P.P.	NULL	NULL	3	3
1002	Sidorov S.S.	NULL	NULL	1	2
1003	Andreev A.A.	NULL	NULL	4	3

De. som et resultat ble vi kvitt lagringen av overflødig informasjon. Nå, ved posisjon og avdelingsnummer, kan vi unikt bestemme navnene deres ved å bruke verdiene i referansetabellene:

VELG e.ID, e.Name, p.Name Stillingsnavn, d.Name Avdelingsnavn FRA Ansatte e LEFT JOIN Avdelinger d ON d.ID = e.DepartmentID LEFT JOIN Stillinger p ON p.ID = e.PositionID

I objektinspektøren kan vi se alle objektene som er opprettet for denne tabellen. Herfra kan du utføre ulike manipulasjoner med disse objektene - for eksempel endre navn på eller slette objekter.

Det er også verdt å merke seg at tabellen kan referere til seg selv, dvs. du kan lage en rekursiv lenke. La oss for eksempel legge til et annet ManagerID-felt i tabellen vår med ansatte, som vil peke på den ansatte som denne ansatte er underordnet. La oss lage et felt:

ENDRINGSTABELL Ansatte ADD ManagerID int
NULL er tillatt i dette feltet, feltet vil være tomt dersom det for eksempel ikke er overordnede over den ansatte.

La oss nå lage en UTENLANDSKE NØKKEL på Employees-tabellen:

ENDRINGSTABELL Ansatte ADD CONSTRAINT FK_Employees_ManagerID UTENLANDSKE NØKKEL (ManagerID) REFERANSER Ansatte (ID)
La oss nå lage et diagram og se hvordan relasjonene mellom tabellene våre ser ut på den:

Som et resultat bør vi se følgende bilde (tabellen Ansatte er koblet til tabellene Stillinger og Avdelinger, og refererer også til seg selv):

Til slutt skal det sies at referansenøkler kan inkludere flere alternativer ON DELETE CASCADE og ON UPDATE CASCADE, som forteller hvordan man skal oppføre seg når man sletter eller oppdaterer en post som er referert til i referansetabellen. Hvis disse alternativene ikke er spesifisert, kan vi ikke endre ID i referansetabellen for posten som det er lenker til fra en annen tabell, også vil vi ikke kunne slette en slik post fra referansen før vi sletter alle linjer som refererer til denne posten, eller vi vil oppdatere koblingene i disse linjene til en annen verdi.

La oss for eksempel gjenskape tabellen med ON DELETE CASCADE-alternativet for FK_Employees_DepartmentID:

DROP TABLE Ansatte OPPRETT TABELL Ansatte (ID int NOT NULL, Navn nvarchar (30), bursdagsdato, e-post nvarchar (30), PositionID int, DepartmentID int, ManagerID int, BEGRENSNING PK_Employees PRIMARY KEY (ID), CONSTRAINT EIGN_Department (CONSTRAINT EIGNDepartment) ) REFERANSER Avdelinger (ID) PÅ SLETT CASCADE, BEGRENSNING FK_Employees_PositionID FOREIGN KEY (PositionID) REFERANSER Stillinger (ID), CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) REFERENCES Stillinger ID (IDS0), (N Ansettelses-ID, 0,0 "19550219", 2,1, NULL), (1001, N "Petrov PP", "19831203", 3,3,1003), (1002, N "Sidorov SS", "19760607", 1,2,1000) , (1003, N "Andreev AA", "19820417", 4,3,1000)
La oss slette avdelingen med ID 3 fra avdelingstabellen:

SLETT avdelinger WHERE ID = 3
La oss se på dataene i tabellen Ansatte:

VELG * FRA Ansatte

ID	Navn	Fødselsdag	E-post	Posisjons-ID	Avdelings-ID	ManagerID
1000	Ivanov I.I.	1955-02-19	NULL	2	1	NULL
1002	Sidorov S.S.	1976-06-07	NULL	1	2	1000

Som du ser er også dataene for avdeling 3 slettet fra tabellen Ansatte.

Alternativet ON UPDATE CASCADE oppfører seg på samme måte, men det fungerer når ID-verdien i oppslaget er oppdatert. For eksempel, hvis vi endrer stillings-ID i stillingskatalogen, vil avdelings-ID i tabellen Ansatte bli oppdatert til den nye ID-verdien som vi spesifiserte i katalogen. Men i dette tilfellet vil det rett og slett ikke være mulig å demonstrere dette, siden ID-kolonnen i avdelingstabellen har IDENTITY-alternativet, som ikke vil tillate oss å utføre følgende forespørsel (endre avdelings-ID 3 til 30):

OPPDATERING AV avdelinger SET ID = 30 WHERE ID = 3
Det viktigste er å forstå essensen av disse 2 alternativene PÅ SLETT CASCADE og PÅ OPPDATERING AV CASCADE. Jeg bruker disse alternativene i svært sjeldne tilfeller, og jeg anbefaler at du tenker deg nøye om før du bruker dem i en referansebegrensning. hvis du ved et uhell sletter en post fra oppslagstabellen, kan dette føre til store problemer og skape en kjedereaksjon.

La oss gjenopprette avdeling 3:

Gi tillatelse til å legge til / endre IDENTITY-verdi SET IDENTITY_INSERT Avdelinger ON INSERT Avdelinger (ID, navn) VALUES (3, N "IT") - forby å legge til / endre IDENTITY-verdi SET IDENTITY_INSERT Avdelinger AV
La oss rydde opp i Employees-tabellen fullstendig ved å bruke TRUNCATE TABLE-kommandoen:

TRUNCATE TABLE Ansatte
Og igjen, last inn dataene på nytt ved å bruke den forrige INSERT-kommandoen:

INSERT Ansatte (ID, navn, fødselsdag, stillings-ID, avdelings-ID, leder-ID) VERDIER (1000, N "Ivanov I.I.", "19550219", 2,1, NULL), (1001, N "Petrov P.P." , "19831203", 3 ,3,1003), (1002, N "Sidorov SS", "19760607", 1,2,1000), (1003, N "Andreev AA", "19820417" , 4,3,1000)

La oss oppsummere

For øyeblikket er noen flere DDL-kommandoer lagt til vår kunnskap:

• Legge til IDENTITY-egenskapen til et felt - lar deg gjøre dette feltet automatisk fylt (tellerfelt) for tabellen;
• ENDRE TABELL tabellnavn LEGG TIL list_of_fields_with_characteristics - lar deg legge til nye felt i tabellen;
• ENDRE TABELL tabellnavn DROPPE KOLONNE list_of_field - lar deg slette felt fra tabellen;
• ENDRE TABELL tabellnavn LEGG TIL BEGRENSNING constraint_name UTENLANDSKE NØKKEL(Enger) REFERANSER reference_table (felt) - lar deg definere forholdet mellom tabellen og referansetabellen.

Andre restriksjoner - UNIK, STANDARD, KONTROLL

Med UNIQUE-begrensningen kan du si at verdiene for hver rad i et gitt felt eller sett med felt må være unike. Når det gjelder tabellen Ansatte, kan vi pålegge en slik begrensning i feltet E-post. Bare forhåndsfyll e-post med verdier, hvis de ikke allerede er definert:

OPPDATERING Ansatte SET E-post = " [e-postbeskyttet]"WHERE ID = 1000 OPPDATERING Ansatte SET E-post =" [e-postbeskyttet]"WHERE ID = 1001 OPPDATERING Ansatte SET E-post =" [e-postbeskyttet]"WHERE ID = 1002 OPPDATERING Ansatte SET E-post =" [e-postbeskyttet]"HVOR ID = 1003
Og nå kan du legge en unikhetsbegrensning på dette feltet:

ENDRINGSTABELL Ansatte ADD CONSTRAINT UQ_Employees_Email UNIQUE (E-post)
Nå vil ikke brukeren kunne legge inn samme e-post for flere ansatte.

Unikitetsbegrensningen heter vanligvis som følger - først kommer prefikset "UQ_", deretter navnet på tabellen, og etter understreken er det navnet på feltet som denne begrensningen brukes på.

Følgelig, hvis en kombinasjon av felt skal være unik i sammenheng med tabellrader, viser vi dem atskilt med komma:

ALTER TABLE tabellnavn LEGG TIL BEGRENSNING begrensningsnavn UNIK (felt1, felt2, ...)
Ved å legge til en DEFAULT-begrensning i feltet, kan vi angi en standardverdi som vil bli erstattet hvis, når du setter inn en ny post, dette feltet ikke er oppført i listen over felt til INSERT-kommandoen. Denne begrensningen kan settes direkte når du oppretter en tabell.

La oss legge til et nytt Avtaledato-felt i Ansatte-tabellen og gi det navnet HireDate og si at standardverdien for dette feltet er gjeldende dato:

ENDRINGSTABELL Ansatte LEGG TIL Ansett dato IKKE NULL STANDARD SYSDATETIME ()
Eller hvis HireDate-kolonnen allerede eksisterer, kan følgende syntaks brukes:

ENDRINGSTABELL Ansatte LEGG TIL STANDARD SYSDATETIME () FOR HireDate
Her spesifiserte jeg ikke navnet på begrensningen, siden i tilfellet DEFAULT var jeg av den oppfatning at dette ikke er så kritisk. Men hvis du gjør det på en vennskapelig måte, så synes jeg, du skal ikke være lat, og du bør gi et normalt navn. Dette gjøres som følger:

ALTER TABLE Ansatte ADD CONSTRAINT DF_Employees_HireDate STANDARD SYSDATETIME () FOR HireDate
Siden denne kolonnen ikke eksisterte før, når den legges til hver post, vil gjeldende datoverdi settes inn i HireDate-feltet.

Når du legger til en ny post, vil gjeldende dato også settes inn automatisk, selvfølgelig, hvis vi ikke eksplisitt setter den, dvs. vil ikke spesifiseres i listen over kolonner. La oss vise dette med et eksempel uten å spesifisere HireDate-feltet i listen over tilleggsverdier:

INSERT Ansatte (ID, navn, e-post) VERDIER (1004, N "Sergeev S.S.", " [e-postbeskyttet]")
La oss se hva som skjedde:

VELG * FRA Ansatte

ID	Navn	Fødselsdag	E-post	Posisjons-ID	Avdelings-ID	ManagerID	LeieDato
1000	Ivanov I.I.	1955-02-19	[e-postbeskyttet]	2	1	NULL	2015-04-08
1001	Petrov P.P.	1983-12-03	[e-postbeskyttet]	3	4	1003	2015-04-08
1002	Sidorov S.S.	1976-06-07	[e-postbeskyttet]	1	2	1000	2015-04-08
1003	Andreev A.A.	1982-04-17	[e-postbeskyttet]	4	3	1000	2015-04-08
1004	Sergeev S.S.	NULL	[e-postbeskyttet]	NULL	NULL	NULL	2015-04-08

CHECK-begrensningen brukes når det er nødvendig å kontrollere verdiene som er satt inn i feltet. La oss for eksempel pålegge denne begrensningen på personellnummerfeltet, som er den ansattes identifikator (ID). Ved å bruke denne begrensningen, la oss si at personelltall skal ha en verdi mellom 1000 og 1999:

ENDRINGSTABELL Ansatte ADD BEGRENSNING CK_Employees_ID CHECK (ID MELLOM 1000 OG 1999)
Begrensningen heter vanligvis det samme, først kommer prefikset "CK_", deretter navnet på tabellen og navnet på feltet som denne begrensningen er pålagt.

La oss prøve å sette inn en ugyldig oppføring for å sjekke at begrensningen fungerer (vi bør få den tilsvarende feilen):

INSERT ansatte (ID, e-post) VERDIER (2000, " [e-postbeskyttet]")
La oss nå endre den innsatte verdien til 1500 og sørge for at posten er satt inn:

INSERT ansatte (ID, e-post) VERDIER (1500, " [e-postbeskyttet]")
Du kan også opprette UNIQUE og CHECK-begrensninger uten å spesifisere et navn:

ENDRING TABELL Ansatte LEGG TIL UNIK (E-post) ENDRING TABELL Ansatte LEGG TIL KONTROLL (ID MELLOM 1000 OG 1999)
Men dette er ikke en god praksis, og det er bedre å spesifisere navnet på begrensningen eksplisitt, siden for å finne ut av det senere, som vil være vanskeligere, må du åpne objektet og se hva det er ansvarlig for.

Med et godt navn kan mye informasjon om begrensningen gjenkjennes direkte på navnet.

Og følgelig kan alle disse begrensningene opprettes umiddelbart når du oppretter en tabell, hvis den ikke allerede eksisterer. La oss slette tabellen:

DROP TABLE Ansatte
Og vi vil gjenskape den med alle opprettede restriksjoner med én CREATE TABLE-kommando:

LAG TABELL Ansatte (ID int NOT NULL, Navn nvarchar (30), bursdagsdato, e-post nvarchar (30), PositionID int, DepartmentID int, HireDate dato IKKE NULL STANDARD SYSDATETIME (), - for STANDARD vil jeg kaste CONSTRAINT PK_Employees unntak PRIMÆR (ID), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY (DepartmentID) REFERENCES Avdelinger (ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY (PositionID) REFERENCES Posisjoner (ID), CONSTRAINT UQ_Employees_Email) UNIQUE (Email)

INSERT ansatte (ID, navn, bursdag, e-post, stillings-ID, avdelings-ID) VERDIER (1000, N "Ivanov I.I.", "19550219", " [e-postbeskyttet]", 2,1), (1001, N" Petrov P.P. "," 19831203 "," [e-postbeskyttet]", 3,3), (1002, N" Sidorov S.S. "," 19760607 "," [e-postbeskyttet]", 1,2), (1003, N" Andreev A.A. "," 19820417 "," [e-postbeskyttet]",4,3)

Litt om indekser opprettet når du oppretter PRIMÆR NØKKEL og UNIKE begrensninger

Som du kan se i skjermbildet ovenfor, ble det automatisk opprettet indekser med samme navn (PK_Employees og UQ_Employees_Email) når du oppretter PRIMÆRKØKKEL og UNIKE begrensninger. Som standard er indeksen for primærnøkkelen opprettet som KLUSTERET, og for alle andre indekser som IKKE KLUSTERET. Det skal sies at ikke alle DBMS har konseptet med en klynget indeks. En tabell kan bare ha én KLUSTERET indeks. CLUSTERED - betyr at tabellposter vil bli sortert etter denne indeksen, man kan også si at denne indeksen har direkte tilgang til alle tabelldata. Dette er tabellens hovedindeks, for å si det sånn. Mer grovt sett er det en indeks boltet til bordet. Den grupperte indeksen er et veldig kraftig verktøy som kan hjelpe deg med å optimalisere søkene dine, bare ha det i bakhodet for nå. Hvis vi vil fortelle at den grupperte indeksen ikke skal brukes i primærnøkkelen, men for en annen indeks, må vi spesifisere alternativet IKKE CLUSTERED når vi oppretter primærnøkkelen:

ALTER TABLE tabellnavn LEGG TIL BEGRENSNING begrensningsnavn PRIMÆR NØKKEL IKKE KLUSTERET (felt1, felt2, ...)
La oss for eksempel gjøre PK_Employees-begrensningsindeksen ikke-klynget og UQ_Employees_Email-begrensningsindeksen klynget. Først av alt fjerner vi disse begrensningene:

ENDRE TABELL Ansatte SLIPPER BEGRENSNING PK_Ansatte ENDRING TABELL Ansatte SLIPPER BEGRENSNING UQ_Employees_Email
La oss nå lage dem med alternativene CLUSTERED og IKKE-CLUSTERED:

ENDRE TABELL Ansatte ADD CONSTRAINT PK_Employees PRIMÆR NØKKEL IKKE KLUSTERET (ID) ENDRING TABELL Ansatte ADD CONSTRAINT UQ_Employees_Email UNIQUE CLUSTERED (E-post)
Nå, etter å ha hentet fra tabellen Employees, kan vi se at postene er sortert etter den grupperte UQ_Employees_Email-indeksen:

VELG * FRA Ansatte

ID	Navn	Fødselsdag	E-post	Posisjons-ID	Avdelings-ID	LeieDato
1003	Andreev A.A.	1982-04-17	[e-postbeskyttet]	4	3	2015-04-08
1000	Ivanov I.I.	1955-02-19	[e-postbeskyttet]	2	1	2015-04-08
1001	Petrov P.P.	1983-12-03	[e-postbeskyttet]	3	3	2015-04-08
1002	Sidorov S.S.	1976-06-07	[e-postbeskyttet]	1	2	2015-04-08

Før dette, når PK_Employees-indeksen var den grupperte indeksen, ble postene sortert etter ID som standard.

Men i dette tilfellet er dette bare et eksempel som viser essensen av den grupperte indeksen, siden mest sannsynlig vil forespørsler bli gjort til tabellen Ansatte ved ID-feltet, og i noen tilfeller kan det i seg selv fungere som en oppslagsbok.

For oppslag er det vanligvis tilrådelig at den grupperte indeksen bygges på primærnøkkelen, siden i forespørsler refererer vi ofte til en katalogidentifikator for å få for eksempel navnet (Posisjon, Avdeling). Her husker vi det jeg skrev ovenfor, at den grupperte indeksen har direkte tilgang til radene i tabellen, og av dette følger det at vi kan få verdien av en hvilken som helst kolonne uten ekstra overhead.

Det er fordelaktig å bruke en gruppert indeks på de feltene som oftest samples.

Noen ganger opprettes en nøkkel i tabeller av et surrogatfelt, i så fall er det nyttig å lagre CLUSTERED indeksalternativet for en mer passende indeks og spesifisere IKKE CLUSTERED når du oppretter en surrogat primærnøkkel.

La oss oppsummere

På dette stadiet ble vi kjent med alle typer begrensninger, i deres enkleste form, som er opprettet av en kommando av formen "ENDRE TABELL tabellnavn ADD CONSTRAINT constraint_name ...":

• PRIMÆRNØKKEL- primærnøkkel;
• UTENLANDSKE NØKKEL- sette opp lenker og kontrollere referanseintegriteten til data;
• UNIK- lar deg skape unikhet;
• KRYSS AV- tillater riktigheten av de angitte dataene;
• MISLIGHOLDE- lar deg angi standardverdien;
• Det er også verdt å merke seg at alle restriksjoner kan fjernes ved å bruke kommandoen " ENDRE TABELL tabellnavn DROPPSBEGRENSNING constraint_name ".

Vi berørte også delvis temaet indekser og analyserte begrepet klynge ( KLUSTERET) og ikke-gruppert ( IKKE-KLUSTERET) indeks.

Lag frittstående indekser

Selvtillit refererer her til indekser som ikke er opprettet for en PRIMÆRKØKKEL eller UNIK begrensning.

Indekser etter felt eller felt kan opprettes med følgende kommando:

CREATE INDEX IDX_Employees_Name ON Employees (Name)
Også her kan du spesifisere alternativene CLUSTERED, IKKE-KLUSTERET, UNIQUE, og du kan også spesifisere sorteringsretningen for hvert enkelt felt ASC (som standard) eller DESC:

LAG UNIK IKKE-KLUSTERET INDEKS UQ_Employees_EmailDesc ON Ansatte (E-post DESC)
Når du oppretter en ikke-klynget indeks, kan alternativet IKKE-KLUSTERET frigis fordi det er standard, og vises her ganske enkelt for å indikere posisjonen til CLUSTERED eller IKKE-CLUSTERED-alternativet i kommandoen.

Du kan slette indeksen med følgende kommando:

DROP INDEX IDX_Employees_Name ON Ansatte
Enkle indekser, som begrensninger, kan opprettes i konteksten av CREATE TABLE-kommandoen.

La oss for eksempel droppe tabellen igjen:

DROP TABLE Ansatte
Og vi vil gjenskape den med alle opprettede begrensninger og indekser med én CREATE TABLE-kommando:

OPPRETT TABELL Ansatte (ID int NOT NULL, Navn nvarchar (30), bursdagsdato, e-post nvarchar (30), PositionID int, DepartmentID int, HireDate date NOT NULL CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME (),AnsettelsesID int, CONSTRAINT), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY (DepartmentID) REFERENCES Avdelinger (ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY (PositionID) REFERENCES Posisjoner (ID), CONSTRAINT FK_Employees_ManagerID FOREIGN NØKKEL (10m) (EXTRAINT 1_0m) CHECK (1E9m) (EXP400)
Til slutt, la oss sette inn våre ansatte i tabellen:

INSERT ansatte (ID, navn, bursdag, e-post, stillings-ID, avdelings-ID, leder-ID) VERDIER (1000, N "Ivanov I.I.", "19550219", " [e-postbeskyttet]", 2,1, NULL), (1001, N" Petrov P.P. "," 19831203 "," [e-postbeskyttet]", 3,3,1003), (1002, N" Sidorov S.S. "," 19760607 "," [e-postbeskyttet]", 1,2,1000), (1003, N" Andreev A.A. "," 19820417 "," [e-postbeskyttet]",4,3,1000)
I tillegg er det verdt å merke seg at du kan inkludere verdier i en ikke-klynget indeks ved å spesifisere dem i INCLUDE. De. i dette tilfellet vil INCLUDE-indeksen ligne noe på en klynget indeks, bare nå er ikke indeksen boltet til bordet, men de nødvendige verdiene er boltet til indeksen. Følgelig kan slike indekser forbedre ytelsen til utvalgte spørringer (SELECT), hvis alle de oppførte feltene er til stede i indeksen, kan det hende at det ikke er nødvendig å få tilgang til tabellen i det hele tatt. Men dette øker naturligvis størrelsen på indeksen, siden verdiene til de oppførte feltene dupliseres i indeksen.

Utdrag fra MSDN. Generell kommandosyntaks for å lage indekser

LAG [UNIKK] [KLUSTERET | IKKE KLUSTERET] INDEX index_name PÅ