En illustrerad självstudieguide till SQL för nybörjare. Kategoriarkiv: Böcker om SQL sql-programmeringsspråket för dummies

Från författaren: Har du blivit kallad tekanna? Nåväl, det här går att fixa! Varje samovar var en gång en tekanna! Eller var varje proffs en gång en samovar? Nej, igen är något fel! Allt som allt är MySQL för nybörjare.

Varför dummies behöver MySQL

Om du på allvar ska koppla ihop ditt liv med Internet, kommer du vid de allra första stegen i "webben" att stöta på detta DBMS. MySQL kan säkert kallas "hela Internet" databashanteringssystem. Inte en enda mer eller mindre seriös resurs kan klara sig utan den, den finns i administratörspanelen för varje värd. Och mest av allt populära CMS och till och med egentillverkade motorer byggs med hennes deltagande.

I allmänhet kan du inte klara dig utan denna plattform. Men för att studera det behöver du också rätt tillvägagångssätt, rätt verktyg och viktigast av allt, lust och tålamod. Jag hoppas att du har gott om det sistnämnda. Och var beredd på det faktum att dina hjärnor kommer att koka och ånga kommer att ramla ut ur ditt huvud, som från en riktig tekanna

Men MySQL är så svårt för dummies bara om du börjar lära dig det fel. Vi kommer inte att göra ett sådant misstag, och vi kommer att börja vår bekantskap med denna teknik från första början.

Grundläggande koncept

Låt oss först gå igenom de grundläggande begreppen som vi kommer att nämna i det här inlägget:

Databas (DB) är den huvudsakliga ingående enheten i DBMS. Databasen innehåller tabeller som består av kolumner och poster (rader). Cellerna som bildas i skärningspunkten innehåller strukturerad data av en viss typ.

DBMS (databashanteringssystem) - en uppsättning av alla programvarumoduler för databasadministration.

SQL är ett strukturerat frågespråk, med hjälp av vilket utvecklaren "kommunicerar" med kärnan (servern) i DBMS. Som alla programmeringsspråk har SQL sin egen syntax, uppsättning kommandon och operatorer, datatyper som stöds.

Jag tror att vi har tillräckligt med teoretisk kunskap till att börja med. Vi kommer att "måla" de saknade luckorna i teorin med praktiken. Nu återstår bara att välja rätt mjukvaruverktyg.

Att hitta rätt verktyg

Efter att ha "rotsat" ganska mycket i hela utbudet av MySQL-skal för nybörjare, insåg jag att dessa helt enkelt inte existerar. Alla mjukvaruprodukter för DBMS-administration kräver en redan installerad databasserver. I allmänhet bestämde jag mig än en gång för att inte återuppfinna "skotern", och valde det inhemska Denwer-paketet. Du kan ladda ner den på den officiella webbplatsen.

Den innehåller redan alla komponenter i DBMS, vilket gör att en nybörjare kan börja praktiskt bekanta sig med MySQL direkt efter en enkel och begriplig installation. Dessutom innehåller Denwer flera andra verktyg som är nödvändiga för en nybörjare: lokal server, PHP.

Första stegen

Jag kommer inte att beskriva installationsprocessen för "herrarnas" set, eftersom allt sker automatiskt där. Efter att ha startat installationen har du bara tid att trycka på de nödvändiga tangenterna. Precis vad du behöver i dummyversionen av MySQL.

När installationsprocessen är över, starta den lokala servern, vänta ett par sekunder. Efter det skriver du localhost i adressfältet i din webbläsare.

På sidan "Hurra, det funkar!" följ en av länkarna på bilden. Därefter kommer du att tas till phpMyAdmin - ett skal för databasadministration.

Genom att klicka på länken http://downloads.mysql.com/docs/world.sql.zip laddar du ner en provdatabas från den officiella MySQL-webbplatsen. Gå till phpMyAdmin igen, i huvudmenyn högst upp gå till fliken "Importera". I fönstret "Importera till aktuell" i det första avsnittet ("Fil som ska importeras") ställer du in värdet "Bläddra i din dator".

I utforskarfönstret väljer du arkivet med den nedladdade exempeldatabasen. Glöm inte att klicka på "Ok" längst ner i huvudfönstret.

Jag råder dig att inte ändra de angivna parametervärdena för nu. Detta kan leda till felaktig visning av data från den importerade källan. Om phpMyAdmin ger ett felmeddelande att den inte kan känna igen databaskomprimeringsalgoritmen, packa upp den och upprepa hela importprocessen från början.

Om allt gick bra, kommer programmeddelandet att visas högst upp att importen lyckades, och till vänster i DB-listan finns ett annat (ord).

Låt oss titta på dess struktur från insidan så att du tydligare kan föreställa dig vad du kommer att behöva ta itu med.

Klicka på namnet på MySQL Database for Beginners. En lista över tabeller som den består av kommer att visas under den. Klicka på en av dem. Gå sedan till toppmenyn "Struktur". Huvudarbetsområdet visar tabellens struktur: alla kolumnnamn, datatyper och alla attribut.

Denna handledning är ungefär en "stämpel av mitt minne" för SQL-språket (DDL, DML), dvs. detta är information som har samlats på mig under min yrkesverksamhet och som ständigt lagras i mitt huvud. Detta är ett tillräckligt minimum för mig, vilket används oftast när man arbetar med databaser. Om det blir nödvändigt att använda mer kompletta SQL-konstruktioner, vänder jag mig vanligtvis till MSDN-biblioteket som finns på Internet för att få hjälp. Enligt mig är det väldigt svårt att hålla allt i huvudet, och det finns inget särskilt behov av detta. Men det är mycket användbart att känna till de grundläggande konstruktionerna, eftersom de är tillämpliga i nästan samma form i många relationsdatabaser som Oracle, MySQL, Firebird. Skillnaderna finns främst i datatyper, som kan skilja sig i detalj. Det finns inte så många grundläggande konstruktioner av SQL-språket, och med konstant övning kommer de snabbt ihåg. Till exempel, för att skapa objekt (tabeller, begränsningar, index, etc.) räcker det att ha en textredigerare för miljön (IDE) till hands för att arbeta med databasen, och det finns inget behov av att studera visuella verktyg som är vässade för arbetar med en specifik typ av databas (MS SQL, Oracle, MySQL, Firebird, ...). Det är också bekvämt eftersom all text ligger framför dina ögon och du behöver inte gå igenom flera flikar för att skapa till exempel ett index eller en begränsning. Med konstant arbete med en databas är det många gånger snabbare att skapa, ändra och speciellt återskapa ett objekt med hjälp av skript än om det görs i visuellt läge. Också i skriptläget (i enlighet därmed, med vederbörlig försiktighet) är det lättare att ställa in och kontrollera reglerna för namngivning av objekt (min subjektiva åsikt). Dessutom är skript bekväma att använda när ändringar som görs i en databas (till exempel en test) måste överföras i samma form till en annan (produktiv) databas.

SQL-språket är uppdelat i flera delar, här kommer jag att diskutera de 2 viktigaste delarna av det:

• DML - Data Manipulation Language, som innehåller följande konstruktioner:
  • SELECT - dataval
  • INSERT - infogar ny data
  • UPPDATERING - datauppdatering
  • DELETE - raderar data
  • MERGE - datasammanfogning

Eftersom Jag är en praktiker, det kommer att finnas lite teori som sådan i denna handledning, och alla konstruktioner kommer att förklaras med praktiska exempel. Dessutom tror jag att ett programmeringsspråk, och speciellt SQL, bara kan bemästras i praktiken, genom att du själv känner på det och förstår vad som händer när du utför den eller den konstruktionen.

Denna handledning är baserad på steg för steg-principen, dvs. det är nödvändigt att läsa den sekventiellt och helst omedelbart efter exemplen. Men om du under vägen har ett behov av att lära dig mer om ett kommando mer detaljerat, använd då en specifik sökning på Internet, till exempel i MSDN-biblioteket.

När jag skrev denna handledning användes MS SQL Server-databasversionen 2014, för att exekvera skripten använde jag MS SQL Server Management Studio (SSMS).

Kort om MS SQL Server Management Studio (SSMS)

SQL Server Management Studio (SSMS) är ett verktyg för Microsoft SQL Server för att konfigurera, hantera och administrera databaskomponenter. Det här verktyget innehåller en skriptredigerare (som vi huvudsakligen kommer att använda) och ett grafiskt program som fungerar med serverobjekt och inställningar. Huvudverktyget i SQL Server Management Studio är Object Explorer, som låter användaren visa, hämta och manipulera serverobjekt. Denna text är delvis lånad från Wikipedia.

För att skapa en ny skriptredigerare, använd knappen Ny fråga:

För att ändra den aktuella databasen kan du använda rullgardinsmenyn:

För att utföra ett specifikt kommando (eller en grupp av kommandon), välj det och tryck på knappen Execute eller F5-tangenten. Om det bara finns ett kommando i editorn för tillfället, eller om du behöver utföra alla kommandon, behöver du inte välja någonting.

Efter att ha kört skript, särskilt de som skapar objekt (tabeller, kolumner, index), för att se ändringarna, använd uppdateringen från snabbmenyn genom att välja lämplig grupp (till exempel tabeller), själva tabellen eller kolumngruppen i den.

Egentligen är detta allt vi behöver veta för att utföra exemplen som ges här. Resten av SSMS-verktyget är lätt att lära sig på egen hand.

Lite teori

En relationsdatabas (RDB, eller vidare i sammanhanget enbart en databas) är en samling tabeller som är sammankopplade. Grovt sett är en databas en fil där data lagras i en strukturerad form.

DBMS - Management System för dessa databaser, dvs. det är en uppsättning verktyg för att arbeta med en specifik typ av databas (MS SQL, Oracle, MySQL, Firebird, ...).

Notera
Eftersom i livet, i vardagligt tal, säger vi mest: "Oracle DB", eller till och med bara "Oracle", som egentligen betyder "Oracle DBMS", då i samband med denna handledning kommer termen DB ibland att användas. Av sammanhanget tror jag att det kommer att framgå vad det handlar om.

En tabell är en samling kolumner. Kolumner kan också kallas fält eller kolumner, alla dessa ord kommer att användas synonymt för att uttrycka samma sak.

Tabellen är huvudobjektet för RDB, all RDB-data lagras rad för rad i tabellens kolumner. Strängar, poster är också synonymer.

För varje tabell, såväl som för dess kolumner, ges namn, genom vilka de sedan nås.
Ett objektnamn (tabellnamn, kolumnnamn, indexnamn, etc.) i MS SQL kan ha en maximal längd på 128 tecken.

Som referens- i ORACLE-databasen kan objektnamn ha en maximal längd på 30 tecken. Därför måste du för en specifik databas utveckla dina egna regler för namngivning av objekt för att hålla dig inom gränsen för antalet tecken.

SQL är ett språk som låter dig köra frågor i en databas med hjälp av ett DBMS. I ett specifikt DBMS kan SQL-språket ha en specifik implementering (sin egen dialekt).

DDL och DML är en delmängd av SQL-språket:

• DDL-språket används för att skapa och modifiera databasstrukturen, d.v.s. för att skapa / ändra / ta bort tabeller och länkar.
• DML-språk tillåter manipulering av tabelldata, d.v.s. med hennes repliker. Det låter dig välja data från tabeller, lägga till ny data i tabeller och uppdatera och radera befintliga data.

Det finns två typer av kommentarer som kan användas i SQL (enradig och flerradig):

En rad kommentar
och

/ * kommentar med flera rader * /

Egentligen kommer detta att räcka för teorin.

DDL - Data Definition Language

Tänk till exempel en tabell med data om anställda, i vanlig form för en person som inte är programmerare:

I detta fall har tabellens kolumner följande namn: Personalnummer, fullständigt namn, Födelsedatum, E-post, Befattning, Avdelning.

Var och en av dessa kolumner kan karakteriseras av den typ av data den innehåller:

• Personalnummer - heltal
• Fullständigt namn - sträng
• Födelsedatum - datum
• E-post - sträng
• Position - sträng
• Avdelning - sträng

Kolumntyp är en egenskap som indikerar vilken typ av data en given kolumn kan lagra.

Till att börja med kommer det att räcka att bara komma ihåg följande grundläggande datatyper som används i MS SQL:

Menande	MS SQL notation	Beskrivning
Snöre med variabel längd	varchar (N) och nvarchar (N)	Med siffran N kan vi ange maximal radlängd för motsvarande kolumn. Om vi ​​till exempel vill säga att värdet på kolumnen "namn" kan innehålla maximalt 30 tecken, måste vi ställa in det på typen nvarchar (30). Skillnaden mellan varchar och nvarchar är att varchar lagrar strängar i ASCII-format, där ett tecken är 1 byte, medan nvarchar lagrar strängar i Unicode-format, där varje tecken är 2 byte. Varchar-typen bör endast användas om du är 100 % säker på att fältet inte behöver lagra Unicode-tecken. Till exempel kan varchar användas för att lagra e-postadresser eftersom de innehåller vanligtvis bara ASCII-tecken.
Snöre med fast längd	röding (N) och nchar (N)	Denna typ skiljer sig från en sträng med variabel längd genom att om strängen är mindre än N tecken lång, så är den alltid utfylld till höger till längden av N med mellanslag och lagras i databasen i denna form, d.v.s. den upptar exakt N tecken i databasen (där ett tecken upptar 1 byte för char och 2 byte för nchar). I min praktik används denna typ väldigt sällan, och om den används så används den främst i char (1)-formatet, dvs. när fältet definieras av ett tecken.
Heltal	int	Denna typ tillåter oss att endast använda heltal i kolumnen, både positiva och negativa. För referens (nu är detta inte så relevant för oss) - intervallet av nummer som int-typen tillåter är från -2 147 483 648 till 2 147 483 647. Vanligtvis är detta huvudtypen som används för att ställa in identifierare.
Verkligt eller verkligt tal	flyta	Enkelt uttryckt är dessa tal där en decimalkomma (komma) kan förekomma.
datum	datum	Om du bara behöver lagra datum i kolumnen, som består av tre komponenter: Antal, Månad och År. Till exempel 2014-02-15 (15 februari 2014). Denna typ kan användas för kolumnen "Antagningsdatum", "Födelsedatum" osv. i de fall då det är viktigt för oss att bara fixa datumet, eller när tidskomponenten inte är viktig för oss och kan kasseras eller om den inte är känd.
Tid	tid	Denna typ kan användas om endast tidsdata behöver lagras i en kolumn, d.v.s. Timmar, minuter, sekunder och millisekunder. Till exempel 17:38: 31.3231603 Till exempel den dagliga "Flight Departure Time".
datum och tid	datum Tid	Denna typ låter dig spara både datum och tid samtidigt. Till exempel, 15.02.2014 17:38: 31.323 Detta kan till exempel vara datum och tid för en händelse.
Flagga	bit	Denna typ är bekväm för att lagra värden som "Ja" / "Nej", där "Ja" kommer att lagras som 1 och "Nej" kommer att lagras som 0.

Dessutom får fältvärdet, om det inte är förbjudet, inte anges, för detta ändamål används nyckelordet NULL.

För att köra exemplen, låt oss skapa en testbas som heter Test.

En enkel databas (utan att ange ytterligare parametrar) kan skapas genom att köra följande kommando:

SKAPA DATABAS Test
Du kan ta bort databasen med kommandot (du bör vara mycket försiktig med detta kommando):

DROP DATABASE Test
För att byta till vår databas kan du köra kommandot:

ANVÄNDNING Test
Alternativt kan du välja Testdatabasen från rullgardinsmenyn i SSMS-menyområdet. När jag arbetar använder jag ofta denna metod för att växla mellan baser.

Nu i vår databas kan vi skapa en tabell med beskrivningarna som de är, med mellanslag och kyrilliska tecken:

SKAPA TABELL [Anställda] ([Personalnummer] int, [Fullständigt namn] nvarchar (30), [Födelsedatum] datum, nvarchar (30), [Position] nvarchar (30), [Avdelning] nvarchar (30))
I det här fallet måste vi lägga namnen inom hakparenteser [...].

Men i databasen, för större bekvämlighet, är det bättre att ange alla namn på objekt i det latinska alfabetet och inte använda mellanslag i namnen. I MS SQL, vanligtvis i det här fallet, börjar varje ord med en stor bokstav, till exempel för fältet "Personnelnummer" skulle vi kunna ange namnet PersonalNumber. Du kan också använda nummer i namnet, till exempel Telefonnummer1.

På en lapp
I vissa DBMS kan följande namnformat "PHONE_NUMBER" vara mer att föredra, till exempel används detta format ofta i ORACLE DB. När man specificerar fältnamnet är det naturligtvis önskvärt att det inte sammanfaller med nyckelorden som används i DBMS.

Av denna anledning kan du glömma syntaxen för hakparenteser och ta bort tabellen [Anställda]:

SLÄPP TABELL [Anställda]
Till exempel kan en tabell med anställda heta "Anställda", och dess fält kan namnges enligt följande:

• ID - Personalnummer (medarbetar-ID)
• Namn - fullständigt namn
• Födelsedag - Födelsedatum
• E-post - E-post
• Position - Position
• Avdelning - Avdelning

Mycket ofta används ordet ID för att namnge identifierarfältet.

Låt oss nu skapa vår tabell:

SKAPA TABELL Anställda (ID int, Namn nvarchar (30), Födelsedag, E-post nvarchar (30), Position nvarchar (30), Department nvarchar (30))
Du kan använda alternativet INTE NULL för att ange obligatoriska kolumner.

För en befintlig tabell kan fälten omdefinieras med följande kommandon:

Uppdaterar ID-fältet ALTER TABLE Anställda ALTER COLUMN ID int NOT NULL - uppdaterar fältet Namn ALTER TABLE Anställda ALTER COLUMN Namn nvarchar (30) NOT NULL

På en lapp
Det allmänna konceptet för SQL-språket för de flesta DBMS förblir detsamma (åtminstone kan jag bedöma detta utifrån de DBMS som jag har arbetat med). Skillnaden mellan DDL i olika DBMS:er ligger huvudsakligen i datatyper (här kan inte bara deras namn skilja sig, utan även detaljerna i deras implementering), detaljerna för implementeringen av SQL-språket kan också skilja sig något (dvs. kärnan i kommandon är desamma, men det kan finnas små skillnader i dialekten, tyvärr, men det finns ingen standard). Genom att känna till grunderna i SQL kan du enkelt byta från ett DBMS till ett annat, eftersom i det här fallet behöver du bara förstå detaljerna i implementeringen av kommandon i det nya DBMS, dvs. i de flesta fall räcker det med en enkel analogi.

Skapa tabell SKAPA TABELL Anställda (ID int, - i ORACLE, int-typ är motsvarande (omslag) för nummer (38) Namn nvarchar2 (30), - nvarchar2 i ORACLE motsvarar nvarchar i MS SQL Födelsedatum, E-post nvarchar2 (30) ) , Position nvarchar2 (30), Department nvarchar2 (30)); - uppdatering av ID- och Name-fälten (här används MODIFY (...) istället för ALTER COLUMN) ALTER TABLE Anställda MODIFIERA (ID int NOT NULL, Namn nvarchar2 (30) NOT NULL); - lägga till PK (i det här fallet ser konstruktionen ut som i MS SQL, den kommer att visas nedan) ALTER TABLE Anställda ADD CONSTRAINT PK_Employees PRIMARY KEY (ID);
För ORACLE finns det skillnader när det gäller implementering av typen varchar2, dess kodning beror på databasinställningarna och texten kan sparas till exempel i UTF-8-kodning. Dessutom kan fältlängden i ORACLE ställas in både i byte och i tecken, för detta används ytterligare alternativ BYTE och CHAR, som anges efter fältlängden, till exempel:

NAME varchar2 (30 BYTE) - fältkapaciteten kommer att vara 30 byte NAME varchar2 (30 CHAR) - fältkapaciteten kommer att vara 30 tecken
Vilket alternativ som kommer att användas som standard BYTE eller CHAR, i fallet med en enkel indikation av typen varchar2 (30) i ORACLE, beror på databasinställningarna, det kan ibland också ställas in i IDE-inställningarna. I allmänhet kan du ibland lätt bli förvirrad, så i fallet med ORACLE, om varchar2-typen används (och detta är ibland motiverat här, till exempel när du använder UTF-8-kodningen), föredrar jag att uttryckligen skriva CHAR ( eftersom det vanligtvis är bekvämare att läsa längden på en sträng med tecken ).

Men i det här fallet, om tabellen redan innehåller vissa data, måste fälten ID och Namn i alla rader i tabellen fyllas i för att kommandona ska kunna utföras framgångsrikt. Låt oss demonstrera detta med ett exempel, infoga data i tabellen i fälten ID, Position och Avdelning, detta kan göras med följande skript:

INFOGA Anställda (ID, Befattning, Avdelning) VÄRDEN (1000, N "Direktor", N "Administration"), (1001, N "Programmerare", N "IT"), (1002, N "Revisor", N "Redovisning" ), (1003, N "Senior Programmer", N "IT")
I det här fallet kommer kommandot INSERT också att generera ett fel, eftersom När vi infogade angav vi inte värdet för det obligatoriska namnfältet.
Om vi ​​redan hade dessa data i den ursprungliga tabellen, skulle kommandot "ALTER TABLE Employees ALTER COLUMN ID int NOT NULL" ha slutförts framgångsrikt, och kommandot "ALTER TABLE Employees ALTER COLUMN Name int NOT NULL" skulle ha genererat ett felmeddelande , att det finns NULL (ospecificerade) värden i fältet Namn.

Lägg till värden för fältet Namn och fyll i uppgifterna igen:

Alternativet INTE NULL kan också användas direkt när du skapar en ny tabell, dvs. i samband med kommandot CREATE TABLE.

Låt oss först ta bort tabellen med kommandot:

DROP TABLE Anställda
Låt oss nu skapa en tabell med obligatoriska kolumner ID och Namn:

SKAPA TABELL Anställda (ID int NOT NULL, Namn nvarchar (30) NOT NULL, Födelsedag, E-post nvarchar (30), Position nvarchar (30), Department nvarchar (30))
Du kan också skriva NULL efter namnet på kolumnen, vilket innebär att NULL-värden (ej specificerade) kommer att tillåtas i den, men detta är inte nödvändigt, eftersom denna egenskap antas som standard.

Om det tvärtom krävs att göra den befintliga kolumnen valfri för fyllning, använder vi följande kommandosyntax:

ALTER TABLE Anställda ALTER KOLUMN Namn nvarchar (30) NULL
Eller bara:

ALTER TABELL Anställda ALTER KOLUMN Namn nvarchar (30)
Med det här kommandot kan vi också ändra typen av fältet till en annan kompatibel typ, eller ändra dess längd. Låt oss till exempel utöka fältet Namn till 50 tecken:

ALTER TABLE Anställda ALTER KOLUMN Namn nvarchar (50)

Primärnyckel

När du skapar en tabell är det önskvärt att den har en unik kolumn eller en uppsättning kolumner som är unik för var och en av dess rader - en post kan identifieras unikt med detta unika värde. Detta värde kallas den primära nyckeln i tabellen. För vår tabell Anställda kan ett sådant unikt värde vara ID-kolumnen (som innehåller "Anställdas personalnummer" - även om detta värde i vårt fall är unikt för varje anställd och inte kan upprepas).

Du kan skapa en primärnyckel till en befintlig tabell med kommandot:

ALTER TABLE Anställda ADD CONSTRAINT PK_Employees PRIMÄRNYCKEL (ID)
Där "PK_Employees" är namnet på den begränsning som är ansvarig för primärnyckeln. Vanligtvis används prefixet "PK_" för att namnge primärnyckeln, följt av tabellnamnet.

Om primärnyckeln består av flera fält, måste dessa fält listas inom parentes, separerade med kommatecken:

ALTER TABLE tabellnamn ADD CONSTRAINT constraint_name PRIMÄRNYCKEL (fält1, fält2, ...)
Det är värt att notera att i MS SQL måste alla fält som ingår i primärnyckeln vara INTE NULL.

Primärnyckeln kan också bestämmas direkt när tabellen skapas, dvs. i samband med kommandot CREATE TABLE. Låt oss ta bort tabellen:

DROP TABLE Anställda
Och låt oss sedan skapa den med följande syntax:

SKAPA TABELL Anställda (ID int NOT NULL, Namn nvarchar (30) NOT NULL, Födelsedag, E-post nvarchar (30), Position nvarchar (30), Department nvarchar (30), BEGRÄNSNING PK_Employees PRIMÄRNYCKEL (ID) - beskriv trots allt PK fält som en begränsning)
Efter skapandet fyller du i uppgifterna i tabellen:

INFOGA Anställda (ID, Befattning, Avdelning, Namn) VÄRDEN (1000, N "Direktor", N "Administration", N "Ivanov I.I."), (1001, N "Programmerare", N "IT", N " Petrov PP " ), (1002, N" Accountant ", N" Accounting ", N" Sidorov SS "), (1003, N" Senior programmerare ", N" IT ", N" Andreev A. A.")
Om primärnyckeln i tabellen endast består av värdena i en kolumn, kan följande syntax användas:

SKAPA TABELL Anställda (ID int NOT NULL CONSTRAINT PK_Employees PRIMARY KEY, - specificera som en egenskap för fältet Namn nvarchar (30) NOT NULL, Födelsedag, E-post nvarchar (30), Position nvarchar (30), Department nvarchar (30))
Faktum är att namnet på begränsningen kan utelämnas, i vilket fall den kommer att tilldelas ett systemnamn (som "PK__Employee__3214EC278DA42077"):

SKAPA TABELL Anställda (ID int NOT NULL, Namn nvarchar (30) NOT NULL, Födelsedag, E-post nvarchar (30), Position nvarchar (30), Department nvarchar (30), PRIMÄRNYCKEL (ID))
Eller:

SKAPA TABELL Anställda (ID int INTE NULL PRIMÄRNYCKEL, Namn nvarchar (30) INTE NULL, Födelsedag, E-post nvarchar (30), Position nvarchar (30), Department nvarchar (30))
Men jag skulle rekommendera att alltid explicit specificera begränsningsnamnet för beständiga tabeller, eftersom med ett uttryckligen angett och förståeligt namn blir det sedan lättare att manipulera det, till exempel kan du radera det:

ÄNDRA TABELL Anställda SLIP BEGRÄNSNING PK_Anställda
Men en så kort syntax, utan att ange namnen på begränsningarna, är bekväm att använda när du skapar temporära databastabeller (namnet på den temporära tabellen börjar med # eller ##), som kommer att raderas efter användning.

Låt oss sammanfatta

Hittills har vi täckt följande kommandon:

• SKAPA BORD table_name (uppräkning av fält och deras typer, begränsningar) - används för att skapa en ny tabell i den aktuella databasen;
• SLÄPP BORD table_name - tjänar till att ta bort en tabell från den aktuella databasen;
• ÄNDRA TABELL tabellnamn ÄNDRA KOLUMN kolumnnamn... - används för att uppdatera typen av en kolumn eller för att ändra dess inställningar (till exempel för att ange NULL- eller NOT NULL-egenskapen);
• ÄNDRA TABELL tabellnamn LÄGG TILL BEGRÄNSNING constraint_name PRIMÄRNYCKEL(fält1, fält2, ...) - lägga till en primärnyckel till en befintlig tabell;
• ÄNDRA TABELL tabellnamn SLAPP BEGRÄNSNING constraint_name - tar bort restriktionen från tabellen.

Lite om tillfälliga bord

Utdrag från MSDN. Det finns två typer av temporära tabeller i MS SQL Server: lokal (#) och global (##). Lokala temporära tabeller är endast synliga för deras skapare tills anslutningen till SQL Server-instansen upphör, så snart de först skapas. Lokala temporära tabeller tas bort automatiskt efter att en användare kopplat från en instans av SQL Server. Globala temporära tabeller är synliga för alla användare under alla anslutningssessioner efter att dessa tabeller har skapats, och tas bort när alla användare som refererar till dessa tabeller kopplar från SQL Server-instansen.

Tillfälliga tabeller skapas i tempdb-systemdatabasen, d.v.s. genom att skapa dem skräpar vi inte ner huvudbasen, annars är de temporära tabellerna helt identiska med vanliga tabeller, de kan också släppas med kommandot DROP TABLE. Lokala (#) temporära tabeller används oftare.

Du kan använda kommandot CREATE TABLE för att skapa en tillfällig tabell:

SKAPA TABELL #Temp (ID int, Namn nvarchar (30))
Eftersom en temporär tabell i MS SQL liknar en vanlig tabell kan du även släppa den själv med kommandot DROP TABLE:

SLAPPTABELL #Temp

Dessutom kan en temporär tabell (som en vanlig tabell själv) skapas och omedelbart fyllas med data som returneras av en fråga med hjälp av syntaxen SELECT ... INTO:

VÄLJ ID, Namn INTO #Temp FRÅN anställda

På en lapp
Implementering av temporära tabeller kan skilja sig åt i olika DBMS. Till exempel, i ORACLE och Firebird DBMS måste strukturen för temporära tabeller definieras i förväg med kommandot CREATE GLOBAL TEMPORARY TABLE som indikerar detaljerna för att lagra data i den, sedan kan användaren se den bland huvudtabellerna och arbeta med den som med ett vanligt bord.

Databasnormalisering - dela upp i deltabeller (referensböcker) och definiera relationer

Vår nuvarande tabell för anställda har nackdelen att användaren i fälten Position och Avdelning kan skriva in vilken text som helst, som i första hand är fylld av fel, eftersom en anställd helt enkelt kan ange "IT" som en avdelning och en andra anställd t.ex. ange "IT-avdelning", vid den tredje "IT". Därmed blir det oklart vad användaren menade, d.v.s. Är dessa anställda anställda på samma avdelning, eller beskrivs användaren själv och det är 3 olika avdelningar? Dessutom kommer vi i det här fallet inte att kunna gruppera uppgifterna korrekt för någon rapport, där det kan krävas att visa antalet anställda i varje avdelnings sammanhang.

Den andra nackdelen är mängden lagring av denna information och dess dubblering, dvs. för varje anställd anges avdelningens fullständiga namn, vilket kräver utrymme i databasen för att lagra varje tecken från avdelningsnamnet.

Den tredje nackdelen är komplexiteten i att uppdatera dessa fält om titeln på en position ändras, till exempel om du behöver byta namn på positionen "Programmerare" till "Junior Programmerare". I det här fallet måste vi göra ändringar på varje rad i tabellen, där positionen är lika med "Programmerare".

För att undvika dessa brister tillämpas den så kallade normaliseringen av databasen - dela upp den i undertabeller, referenstabeller. Det är inte nödvändigt att gå in i teorins djungel och studera vad normala former är, det räcker för att förstå essensen av normalisering.

Låt oss skapa 2 tabeller "Positioner" och "Avdelningar", den första kommer att heta Positioner, och den andra, respektive, Avdelningar:

SKAPA TABELL Positioner (ID int IDENTITET (1,1) INTE NULL BEGRÄNSNING PK_Positions PRIMÄRNYCKEL, Namn nvarchar (30) INTE NULL) SKAPA TABELL Avdelningar (ID int IDENTITET (1,1) INTE NULL BEGRÄNSNING PK_Avdelningar PRIMÄRKEY, (30Namn NULL) ) INTE NULL)
Notera att vi här har använt det nya IDENTITY-alternativet som säger att uppgifterna i ID-kolumnen kommer att numreras automatiskt, med start från 1, med steget 1, d.v.s. när nya poster läggs till kommer de sekventiellt att tilldelas värdena 1, 2, 3, etc. Sådana fält kallas vanligen för automatisk inkrementering. Endast ett fält med egenskapen IDENTITY kan definieras i en tabell, och vanligtvis, men inte nödvändigtvis, är ett sådant fält primärnyckeln för den tabellen.

På en lapp
I olika DBMS kan implementeringen av fält med en räknare göras på sitt eget sätt. I MySQL, till exempel, definieras ett sådant fält med alternativet AUTO_INCREMENT. I ORACLE och Firebird tidigare kunde denna funktionalitet emuleras med SEQUENCE. Men så vitt jag vet har ORACLE nu lagt till alternativet GENERATED AS IDENTITY.

Låt oss fylla dessa tabeller automatiskt baserat på de aktuella data som registrerats i fälten Position och Avdelning i tabellen Anställda:

Fyll i fältet Namn i tabellen Positioner med unika värden från Position-fältet i tabellen Anställda INSERT Positions (Name) SELECT DISTINCT Position FROM Anställda WHERE Position IS NOT NULL - kasta poster vars position inte är specificerad
Låt oss göra samma sak för avdelningstabellen:

INFOGA Avdelningar (Namn) VÄLJ DISTINKT Avdelning FRÅN Anställda DÄR Avdelningen INTE ÄR NULL
Om vi ​​nu öppnar tabellerna för positioner och avdelningar kommer vi att se en numrerad uppsättning värden för ID-fältet:

VÄLJ * FRÅN Positioner

VÄLJ * FRÅN Avdelningar

Dessa tabeller kommer nu att spela rollen som referensböcker för tilldelning av befattningar och avdelningar. Vi kommer nu att hänvisa till jobb- och avdelnings-ID. Låt oss först och främst skapa nya fält i tabellen Anställda för att lagra identifieringsdata:

Lägg till ett fält för positions-ID ALTER TABLE Anställda ADD PositionID int - lägg till ett fält för ID för avdelningen ALTER TABLE Anställda ADD DepartmentID int
Typen av referensfält bör vara densamma som i referenserna, i detta fall är det int.

Du kan också lägga till flera fält i tabellen samtidigt med ett kommando, lista fälten separerade med kommatecken:

ÄNDRA TABELL Anställda ADD PositionID int, DepartmentID int
Nu kommer vi att skriva länkar (referensbegränsningar - FOREIGN KEY) för dessa fält så att användaren inte kan skriva i dessa fält de värden som saknas bland ID-värdena som finns i referensböckerna.

ÄNDRA TABELL Anställda ADD CONSTRAINT FK_Employees_PositionID UTLÄNDLIG KEY (PositionID) REFERENSER Positioner (ID)
Och vi kommer att göra samma sak för det andra fältet:

ÄNDRA TABELL Anställda ADD CONSTRAINT FK_Employees_DepartmentID UTLÄNDSK KEY (AvdelningsID) REFERENSER Avdelningar (ID)
Nu kommer användaren att kunna ange endast ID-värden från motsvarande katalog i dessa fält. Följaktligen, för att använda en ny avdelning eller befattning, måste han först lägga till en ny post i motsvarande katalog. Eftersom positioner och avdelningar lagras nu i kataloger i en enda kopia, för att ändra namnet räcker det att bara ändra det i katalogen.

Namnet på referensrestriktionen är vanligtvis en sammansatt sådan, den består av prefixet "FK_", sedan följer tabellens namn och efter understrecket finns namnet på fältet som refererar till referenstabellens identifierare.

Identifieraren (ID) är vanligtvis ett internt värde som endast används för länkar och vilket värde som lagras där är i de flesta fall absolut likgiltigt, så du behöver inte försöka bli av med hål i nummersekvensen som uppstår under arbetet med tabellen, till exempel efter att ha raderat poster från referensboken.

ALTER TABLE-tabell ADD CONSTRAINT constraint_name UTLÄNDLIG KEY (fält1, fält2, ...) REFERENSER referenstabell (fält1, fält2, ...)
I det här fallet, i tabellen "dir_table", representeras primärnyckeln av en kombination av flera fält (fält1, fält2, ...).

Nu ska vi faktiskt uppdatera fälten PositionID och DepartmentID med ID-värdena från katalogerna. Låt oss använda kommandot DML UPDATE för detta ändamål:

UPPDATERA e SET PositionID = (VÄLJ ID FRÅN Positioner WHERE Name = e.Position), DepartmentID = (VÄLJ ID FRÅN Departments WHERE Name = e.Department) FRÅN Anställda e
Låt oss se vad som hände genom att köra frågan:

VÄLJ * FRÅN Anställda

Det är allt, PositionID och DepartmentID-fälten är fyllda med motsvarande positioner och avdelningar med identifierare, det finns inget behov av Position och Department-fälten i tabellen Anställda, du kan ta bort dessa fält:

ÄNDRA TABELL Anställda SLUTA KOLUMN Befattning, Avdelning
Nu har tabellen fått följande form:

VÄLJ * FRÅN Anställda

ID	namn	Födelsedag	E-post	Positions-ID	Avdelnings-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 där. som ett resultat blev vi av med lagringen av överflödig information. Nu, genom positions- och avdelningsnumren, kan vi unikt bestämma deras namn med hjälp av värdena i referenstabellerna:

VÄLJ e.ID, e.Name, p.Name PositionName, d.Name DepartmentName FRÅN Anställda e LEFT JOIN Avdelningar d ON d.ID = e.DepartmentID LEFT JOIN Positioner p ON p.ID = e.PositionID

I objektinspektören kan vi se alla objekt som skapats för denna tabell. Härifrån kan du utföra olika manipulationer med dessa objekt - till exempel byta namn på eller ta bort objekt.

Det är också värt att notera att tabellen kan hänvisa till sig själv, d.v.s. du kan skapa en rekursiv länk. Låt oss till exempel lägga till ett annat ManagerID-fält i vår tabell med anställda, vilket kommer att peka på den anställde som denna anställd är underordnad. Låt oss skapa ett fält:

ÄNDRA TABELL Anställda ADD ManagerID int
NULL är tillåtet i detta fält, fältet blir tomt om det till exempel inte finns några överordnade ovanför medarbetaren.

Låt oss nu skapa en UTLÄNDSKNYCKEL på tabellen Anställda:

ÄNDRA TABELL Anställda LÄGG TILL BEGRÄNSNING FK_Employees_ManagerID UTLÄNDLIG KEY (ManagerID) REFERENSER Anställda (ID)
Låt oss nu skapa ett diagram och se hur relationerna mellan våra tabeller ser ut på det:

Som ett resultat bör vi se följande bild (tabellen Anställda är länkad till tabellerna Positioner och Avdelningar och hänvisar också till sig själv):

Slutligen är det värt att nämna att referensnycklar kan innehålla ytterligare alternativ ON DELETE CASCADE och ON UPDATE CASCADE, som berättar hur du ska bete dig när du tar bort eller uppdaterar en post som refereras till i referenstabellen. Om dessa alternativ inte är specificerade kan vi inte ändra ID i referenstabellen för posten som det finns länkar till från en annan tabell, och vi kommer inte heller att kunna ta bort en sådan post från referensen förrän vi tar bort alla rader som refererar till denna post eller, vi kommer att uppdatera länkarna på dessa rader till ett annat värde.

Låt oss till exempel återskapa tabellen med alternativet ON DELETE CASCADE för FK_Employees_DepartmentID:

DROP TABLE Anställda SKAPA TABELL Anställda (ID int NOT NULL, Namn nvarchar (30), Födelsedag, E-post nvarchar (30), PositionID int, DepartmentID int, ManagerID int, BEGRÄNSNING PK_Employees PRIMÄRNYCKEL (ID), CONSTRAINT EIGN_Department KEYDELID (DEMEY) ) REFERENSER Avdelningar (ID) PÅ DELETE CASCADE, BEGRÄNSNING FK_Employees_PositionID FOREIGN KEY (PositionID) REFERENCES Positioner (ID), CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) REFERENCES Positions-ID (IDS0), (N ANSTÄLLNINGS-ID (ID), (N 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)
Låt oss ta bort avdelningen med ID 3 från avdelningstabellen:

DELETE Departments WHERE ID = 3
Låt oss titta på uppgifterna i tabellen Anställda:

VÄLJ * FRÅN Anställda

ID	namn	Födelsedag	E-post	Positions-ID	Avdelnings-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 kan se har även uppgifterna för avdelning 3 raderats från tabellen Anställda.

Alternativet ON UPDATE CASCADE fungerar på liknande sätt, men det fungerar när ID-värdet i uppslagningen uppdateras. Om vi ​​till exempel ändrar positions-ID i jobbkatalogen, kommer avdelnings-ID i tabellen Anställda att uppdateras till det nya ID-värdet som vi angav i katalogen. Men i det här fallet kommer det helt enkelt inte att vara möjligt att visa detta, eftersom ID-kolumnen i tabellen Avdelningar har alternativet IDENTITY, vilket inte tillåter oss att utföra följande begäran (ändra avdelnings-ID 3 till 30):

UPPDATERA avdelningar SET ID = 30 WHERE ID = 3
Det viktigaste är att förstå essensen av dessa två alternativ PÅ DELETE CASCADE och PÅ UPPDATERA CASCADE. Jag använder dessa alternativ vid mycket sällsynta tillfällen, och jag rekommenderar att du tänker noga innan du använder dem i en referensrestriktion. om du av misstag raderar en post från uppslagstabellen kan detta leda till stora problem och skapa en kedjereaktion.

Låt oss återställa avdelning 3:

Ge tillåtelse att lägga till/ändra IDENTITY-värde SET IDENTITY_INSERT avdelningar ON INSERT avdelningar (ID, namn) VALUES (3, N "IT") - förbjud att lägga till/ändra IDENTITY-värde SET IDENTITY_INSERT avdelningar AV
Låt oss rensa upp tabellen Employees helt med kommandot TRUNCATE TABLE:

TRUNCATE TABLE Anställda
Och återigen, ladda om data i den med det föregående INSERT-kommandot:

INFOGA anställda (ID, namn, födelsedag, positions-ID, avdelnings-ID, chefs-ID) VÄRDEN (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)

Låt oss sammanfatta

För tillfället har några fler DDL-kommandon lagts till för vår kunskap:

• Lägga till IDENTITY-egenskapen i ett fält - låter dig göra detta fält automatiskt ifyllt (räknarfält) för tabellen;
• ÄNDRA TABELL tabellnamn LÄGG TILL list_of_fields_with_characteristics - låter dig lägga till nya fält i tabellen;
• ÄNDRA TABELL tabellnamn SLIPP KOLUMN list_of_field - låter dig ta bort fält från tabellen;
• ÄNDRA TABELL tabellnamn LÄGG TILL BEGRÄNSNING constraint_name FRÄMMANDE NYCKEL(fält) REFERENSER referenstabell (fält) - låter dig definiera förhållandet mellan tabellen och referenstabellen.

Andra begränsningar - UNIK, DEFAULT, KONTROLL

Med UNIQUE-begränsningen kan du säga att värdena för varje rad i ett givet fält eller uppsättning fält måste vara unika. När det gäller tabellen Anställda kan vi införa en sådan begränsning i fältet E-post. Fyll bara i e-postmeddelandet med värden i förväg, om de inte redan är definierade:

UPPDATERA Anställda SET E-post = " [e-postskyddad]"WHERE ID = 1000 UPPDATERING Anställda SET E-post =" [e-postskyddad]"WHERE ID = 1001 UPPDATERING Anställda SET E-post =" [e-postskyddad]"WHERE ID = 1002 UPPDATERING Anställda SET E-post =" [e-postskyddad]"WHERE ID = 1003
Och nu kan du införa ett unikt krav på detta område:

ÄNDRA TABELL Anställda ADD CONSTRAINT UQ_Employees_Email UNIQUE (E-post)
Nu kommer användaren inte att kunna ange samma e-post för flera anställda.

Unikitetsbegränsningen heter vanligtvis enligt följande - först kommer prefixet "UQ_", sedan namnet på tabellen, och efter understrecket finns namnet på fältet som denna begränsning tillämpas på.

Följaktligen, om en kombination av fält ska vara unik i sammanhanget med tabellrader, listar vi dem separerade med kommatecken:

ALTER TABLE tabellnamn ADD CONSTRAINT constraint_name UNIQUE (fält1, fält2, ...)
Genom att lägga till en DEFAULT-begränsning i fältet kan vi ställa in ett standardvärde som kommer att ersättas om, när du infogar en ny post, detta fält inte finns med i listan över fält för kommandot INSERT. Denna begränsning kan ställas in direkt när du skapar en tabell.

Låt oss lägga till ett nytt fält för mötesdatum i tabellen Anställda och namnge det HireDate och säga att standardvärdet för detta fält är det aktuella datumet:

ÄNDRA TABELL Anställda ADD Anställningsdatum datum INTE NULL STANDARD SYSDATETIME ()
Eller om kolumnen HireDate redan finns kan följande syntax användas:

ÄNDRA TABELL Anställda LÄGG TILL STANDARD SYSDATETIME () FÖR HireDate
Här har jag inte angett namnet på begränsningen, eftersom i fallet med DEFAULT ansåg jag att detta inte är så kritiskt. Men om man gör det på ett vänskapligt sätt, då tycker jag att man inte ska vara lat och man ska ge ett vanligt namn. Detta görs på följande sätt:

ALTER TABLE Anställda ADD CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME () FÖR HireDate
Eftersom den här kolumnen inte fanns tidigare, när den läggs till i varje post, kommer det aktuella datumvärdet att infogas i fältet HireDate.

Vid tillägg av en ny post kommer även aktuellt datum att infogas automatiskt, naturligtvis, om vi inte uttryckligen ställer in det, d.v.s. kommer inte att anges i listan med kolumner. Låt oss visa detta med ett exempel utan att ange fältet HireDate i listan över mervärden:

INFOGA anställda (ID, namn, e-post) VÄRDEN (1004, N "Sergeev S.S.", " [e-postskyddad]")
Låt oss se vad som hände:

VÄLJ * FRÅN Anställda

ID	namn	Födelsedag	E-post	Positions-ID	Avdelnings-ID	ManagerID	HireDate
1000	Ivanov I.I.	1955-02-19	[e-postskyddad]	2	1	NULL	2015-04-08
1001	Petrov P.P.	1983-12-03	[e-postskyddad]	3	4	1003	2015-04-08
1002	Sidorov S.S.	1976-06-07	[e-postskyddad]	1	2	1000	2015-04-08
1003	Andreev A.A.	1982-04-17	[e-postskyddad]	4	3	1000	2015-04-08
1004	Sergeev S.S.	NULL	[e-postskyddad]	NULL	NULL	NULL	2015-04-08

CHECK-begränsningen används när det är nödvändigt att kontrollera de värden som infogats i fältet. Låt oss till exempel införa denna begränsning på personalnummerfältet, som är den anställdes identifierare (ID). Med hjälp av denna begränsning, låt oss säga att personalnummer bör ha ett värde mellan 1000 och 1999:

ÄNDRA TABELL Anställda ADD CONSTRAINT CK_Employees_ID CHECK (ID MELLAN 1000 OCH 1999)
Begränsningen heter vanligtvis samma, först kommer prefixet "CK_", sedan namnet på tabellen och namnet på fältet som denna begränsning är pålagd.

Låt oss försöka infoga en ogiltig post för att kontrollera att begränsningen fungerar (vi bör få motsvarande fel):

INFOGA anställda (ID, e-post) VÄRDEN (2000, " [e-postskyddad]")
Låt oss nu ändra det infogade värdet till 1500 och se till att posten infogas:

INFOGA anställda (ID, e-post) VÄRDEN (1500, " [e-postskyddad]")
Du kan också skapa UNIQUE och CHECK-begränsningar utan att ange ett namn:

ALTER TABLE Anställda LÄGG TILL UNIK (E-post) ÄNDRA TABELL Anställda LÄGG TILL KONTROLL (ID MELLAN 1000 OCH 1999)
Men detta är inte en bra praxis och det är bättre att ange namnet på begränsningen uttryckligen, eftersom för att ta reda på det senare, vilket kommer att bli svårare, måste du öppna objektet och se vad det är ansvarigt för.

Med ett bra namn kan mycket information om begränsningen kännas igen direkt på dess namn.

Och följaktligen kan alla dessa begränsningar skapas omedelbart när du skapar en tabell, om den inte redan finns. Låt oss ta bort tabellen:

DROP TABLE Anställda
Och vi kommer att återskapa det med alla skapade begränsningar med ett CREATE TABLE-kommando:

SKAPA TABELL Anställda (ID int NOT NULL, Namn nvarchar (30), Födelsedag, E-post nvarchar (30), PositionID int, DepartmentID int, Anställningsdatum INTE NULL STANDARD SYSDATETIME (), - för DEFAULT kommer jag att kasta CONSTRAINT PK_Employees undantag PRIMÄRT (ID), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY (DepartmentID) REFERENCES Avdelningar (ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY (PositionID) REFERENCES Positioner (ID), CONSTRAINT UQ_Employees_Email) UNIQUE (Email)

INFOGA anställda (ID, namn, födelsedag, e-post, positions-ID, avdelnings-ID) VÄRDEN (1000, N "Ivanov I.I.", "19550219", " [e-postskyddad]", 2,1), (1001, N" Petrov P.P. "," 19831203 "," [e-postskyddad]", 3,3), (1002, N" Sidorov S.S. "," 19760607 "," [e-postskyddad]", 1,2), (1003, N" Andreev A.A. "," 19820417 "," [e-postskyddad]",4,3)

Lite om index som skapas när man skapar PRIMÄRKEY och UNIKA begränsningar

Som du kan se i skärmdumpen ovan skapades index med samma namn (PK_Employees och UQ_Employees_Email) automatiskt när du skapade PRIMÄRKEY och UNIQUE begränsningar. Som standard skapas indexet för primärnyckeln som CLUSTERED, och för alla andra index som ICKE CLUSTERED. Det ska sägas att inte alla DBMS har konceptet med ett klustrat index. En tabell kan bara ha ett CLUSTERED index. CLUSTERED - betyder att tabellposter kommer att sorteras efter detta index, man kan också säga att detta index har direkt tillgång till all tabelldata. Detta är så att säga tabellens huvudindex. Mer grovt är det ett index som är fastskruvat i bordet. Det klustrade indexet är ett mycket kraftfullt verktyg som kan hjälpa dig att optimera dina frågor, tänk bara på det för nu. Om vi ​​vill tala om för det klustrade indexet att det inte ska användas i primärnyckeln, utan för ett annat index, måste vi när vi skapar primärnyckeln ange alternativet NOCLUSTERED:

ALTER TABLE tabellnamn LÄGG TILL BEGRÄNSNING begränsningsnamn PRIMÄRNYCKEL ICKELUSTERAD (fält1, fält2, ...)
Låt oss till exempel göra PK_Employees-begränsningsindexet icke-klustrat och UQ_Employees_Email-begränsningsindexet klustrat. Först och främst tar vi bort dessa begränsningar:

ALTER TABLE Anställda SLÄPP BEGRÄNSNING PK_Anställda ÄNDRA TABELL Anställda SLÄPP KONSTRAINT UQ_Anställda_E-post
Låt oss nu skapa dem med alternativen CLUSTERED och NOCLUSTERED:

ÄNDRA TABELL Anställda LÄGG TILL BEGRÄNSNING PK_Anställda PRIMÄRNYCKEL EJ KLUSTERAD (ID) ÄNDRA TABELL Anställda LÄGG TILL BEGRÄNSNING UQ_Employees_Email UNIQUE CLUSTERED (E-post)
Nu, efter att ha hämtat från tabellen Employees, kan vi se att posterna är sorterade efter det klustrade UQ_Employees_Email-indexet:

VÄLJ * FRÅN Anställda

ID	namn	Födelsedag	E-post	Positions-ID	Avdelnings-ID	HireDate
1003	Andreev A.A.	1982-04-17	[e-postskyddad]	4	3	2015-04-08
1000	Ivanov I.I.	1955-02-19	[e-postskyddad]	2	1	2015-04-08
1001	Petrov P.P.	1983-12-03	[e-postskyddad]	3	3	2015-04-08
1002	Sidorov S.S.	1976-06-07	[e-postskyddad]	1	2	2015-04-08

Före detta, när PK_Employees-indexet var det klustrade indexet, sorterades poster efter ID som standard.

Men i det här fallet är detta bara ett exempel som visar essensen av det klustrade indexet, eftersom sannolikt kommer frågor att göras till tabellen Anställda av ID-fältet, och i vissa fall kan det i sig fungera som en referensbok.

För uppslagningar är det vanligtvis tillrådligt att det klustrade indexet byggs på primärnyckeln, eftersom i förfrågningar hänvisar vi ofta till en katalogidentifierare för att få till exempel namnet (Position, Department). Här minns vi vad jag skrev ovan, att det klustrade indexet har direkt tillgång till raderna i tabellen, och av detta följer att vi kan få värdet på vilken kolumn som helst utan extra overhead.

Det är fördelaktigt att tillämpa ett klustrat index på de fält som samplades oftast.

Ibland skapas en nyckel i tabeller av ett surrogatfält, i vilket fall det är användbart att spara alternativet CLUSTERED index för ett mer lämpligt index och ange alternativet ICKELUSTERED när du skapar en surrogat primärnyckel.

Låt oss sammanfatta

I detta skede har vi bekantat oss med alla typer av restriktioner, i deras enklaste form, som skapas av ett kommando av formen "ALTER TABLE table_name ADD CONSTRAINT constraint_name ...":

• PRIMÄRNYCKEL- primärnyckel;
• FRÄMMANDE NYCKEL- upprätta länkar och kontrollera datas referensintegritet;
• UNIK- låter dig skapa unika;
• KOLLA UPP- tillåter korrektheten av de inmatade uppgifterna;
• STANDARD- låter dig ställa in standardvärdet;
• Det är också värt att notera att alla begränsningar kan tas bort med kommandot " ÄNDRA TABELL tabellnamn SLAPP BEGRÄNSNING constraint_name ".

Vi berörde också delvis ämnet index och analyserade begreppet kluster ( KLUSTERAD) och icke-klustrade ( ICLUSTERAD) index.

Skapa fristående index

Självtillit syftar här på index som inte är skapade för en PRIMÄRNYCKEL eller UNIK begränsning.

Index efter fält eller fält kan skapas med följande kommando:

SKAPA INDEX IDX_Employees_Name ON Anställda (namn)
Även här kan du ange alternativen CLUSTERED, NOCLUSTERED, UNIQUE, och du kan också ange sorteringsriktningen för varje enskilt fält ASC (som standard) eller DESC:

SKAPA UNIKT INKLUSTERAT INDEX UQ_Employees_EmailDesc ON Anställda (E-post DESC)
När du skapar ett icke-klustrat index kan alternativet ICKELUSTERAD släppas eftersom det är standard och visas här helt enkelt för att indikera positionen för alternativet CLUSTERED eller NOCLUSTERED i kommandot.

Du kan ta bort indexet med följande kommando:

SLÄPP INDEX IDX_Employees_Name ON Anställda
Enkla index, som begränsningar, kan skapas i samband med kommandot CREATE TABLE.

Låt oss till exempel släppa tabellen igen:

DROP TABLE Anställda
Och vi kommer att återskapa det med alla skapade begränsningar och index med ett CREATE TABLE-kommando:

SKAPA TABELL Anställda (ID int NOT NULL, Namn nvarchar (30), Födelsedag, E-post nvarchar (30), PositionID int, DepartmentID int, HireDate date NOT NULL CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME (), AnställdsID int, CONSTRAINT), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY (DepartmentID) REFERENCES Avdelningar (ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY (PositionID) REFERENCES Positioner (ID), BEGRÄNSNING FK_Employees_ManagerID TWEEEEN KEY (19m) KONTROLLERA (IDE 9m) (IDE_9m) KONTROLLERA 1_09M
Låt oss slutligen infoga våra anställda i tabellen:

INFOGA anställda (ID, namn, födelsedag, e-post, positions-ID, avdelnings-ID, chefs-ID) VÄRDEN (1000, N "Ivanov I.I.", "19550219", " [e-postskyddad]", 2,1, NULL), (1001, N" Petrov P.P. "," 19831203 "," [e-postskyddad]", 3,3,1003), (1002, N" Sidorov S.S. "," 19760607 "," [e-postskyddad]", 1,2,1000), (1003, N" Andreev A.A. "," 19820417 "," [e-postskyddad]",4,3,1000)
Dessutom är det värt att notera att du kan inkludera värden i ett icke-klustrat index genom att ange dem i INCLUDE. De där. i det här fallet kommer INCLUDE-indexet något att likna ett klustrat index, bara nu är indexet inte bultat till bordet, men de nödvändiga värdena är bultade till indexet. Följaktligen kan sådana index avsevärt förbättra prestandan för urvalsfrågor (SELECT), om alla de listade fälten finns i indexet kanske det inte är nödvändigt att komma åt tabellen alls. Men detta ökar naturligtvis storleken på indexet, sedan värdena för de listade fälten dupliceras i indexet.

Utdrag från MSDN. Allmän kommandosyntax för att skapa index

SKAPA [UNIKT] [KLUSTERAD | INKLUSTERAD] INDEX index_name PÅ