Книгата на Алън Бюли, експерт по езика SQL, е отличен учебник за тези, които все още не знаят, но искат да овладеят този език. Книгата не само ще ви позволи да придобиете основни знания, но и ще ви разкаже за най-често използваните мощни функции на езика SQL, използван от опитни програмисти. Много книги за SQL обикновено са скучни в представянето на основите. Тук авторът, в стила на оживена история, обсъжда SQL изрази и блокове, Различни видовеусловия, показва как да създавате заявки в множество таблици чрез обединяване на таблици, разглежда набори от данни и как те могат да си взаимодействат в заявки, демонстрира вградени и обобщени функции, показва как и къде се използват подзаявки. Подробно са описани различни видове свързване на таблици, използването на условна логика, работа с транзакции, индекси и ограничения. Тъй като най-добрият начин да научите SQL е чрез практика, авторът създава база данни за обучение MySQL и предоставя много опции за заявки от реалния свят, които покриват целия теоретичен материал. С този подход е просто невъзможно да не се научите. Можете да използвате примерите за код във вашите програми и документация. Книгата е предназначена за разработчици на приложения за бази данни, администратори на бази данни и тези, които създават отчети.

Произведението принадлежи към жанра Компютри: други. От нашия уебсайт можете да изтеглите книгата "Изучаване на SQL" във формат fb2, rtf, epub, pdf, txt или да четете онлайн. Тук, преди да прочетете, можете също да се обърнете към рецензии на читатели, които вече са запознати с книгата, и да разберете тяхното мнение. В онлайн магазина на нашия партньор можете да закупите и прочетете книгата в хартиен вариант.

Селекция от книги, видео курсове и онлайн ресурси за изучаване на бази данни, основите на релационната теория и езика SQL.

Книги

Алън Бюли "Изучаване на SQL" (2007)

Тази книга е отличен избор за тези, които са в началото на трънливия път на изучаване на SQL. Това не само ще ви позволи да купувате необходима база основни познания, но също така ще ви разкаже за най-популярните тънкости и мощни функции на езика, който използват опитни програмисти.
Много учебници по бази данни, релационна теория и SQL са пълни със скучни теоретични концепции. Тази книга е приятно изключение поради своя лек, жив стил. Авторът умело представя на читателя информация за SQL изрази и блокове, типове условия, съединения, подзаявки и много други.
За да консолидира придобитите знания на практика, авторът създава база за обучение MySQL и предоставя много практически примери за заявки, обхващащи целия представен теоретичен материал.

Крис Фиали "SQL" (2013)

Книгата се занимава с езиковата версия ANSI SQL-92 (SQL2). Той описва подробно как да използвате езика за заявки за решаване на съответните класове проблеми за извличане и модифициране на данни и работа с обекти от структурата на базата данни. Всички примери са обяснени подробно.
Особено внимание в тази публикация е отделено на разликите в SQL диалектите при реализацията на най-разпространените СУБД: MySQL, Oracle, MS SQL Server и PostgreSQL.
Книгата е предназначена за всеки, който иска самостоятелно да научи езика SQL или да подобри знанията си по тази тема.

Антъни Молинаро „SQL. Колекция от рецепти" (2009)

Тази публикация е предназначена за тези, които вече имат познания по SQL и искат да подобрят уменията си в тази област. Също така ще бъде много полезно за експерти по бази данни, тъй като авторът предлага примери за решаване на проблеми в различни СУБД: DB2, Oracle, PostgreSQL, MySQL и SQL Server.
Книгата ще ви помогне да научите как да използвате SQL за решаване на по-широк кръг от проблеми: от операции в база данни до извличане на данни и предаването им по мрежата към приложения.
Ще научите как да кандидатствате функции на прозорецаи специални оператори, както и усъвършенствани методи за работа със складове за данни: създаване на хистограми, обобщаване на данни в блокове, извършване на агрегиране на плъзгащ се диапазон от стойности, генериране на текущи суми и междинни суми. Ще можете да разширявате редовете в колони и обратно, да опростявате изчисленията в рамките на ред и да разгръщате двойно набора от резултати и да извършвате обхождане на низове, което ви позволява да използвате SQL, за да анализирате низ в знаци, думи или разделен низ елементи. Техниките, предложени от автора, ще ви позволят да оптимизирате кода на вашите приложения и ще отворят нови възможности за вас в езика SQL.

Алекс Кригел и др. „SQL. Библията на потребителя, 2-ро издание (2010 г.)

Книгата е уникална с това, че всяка глава сравнява имплементациите на определени заявки в диалектите на трите водещи СУБД. Това го прави изчерпателно и практично ръководство за езика SQL за разработчици от начинаещи до гурута, нещо като ръководство за работния плот.
Публикацията обхваща теми от самите основи до транзакции и заключвания, функции и сигурност на бази данни.
Има няколко допълнителни теми, представени в края: SQL към XML интеграция, OLAP бизнес разузнаване и др.

Ерик Редмънд, Джим Р. Уилсън "Седем бази данни за седем седмици." Въведение в съвременните бази данни и NoSQL идеологията“ (2015)

Книгата обхваща повечето съвременни бази данни с отворен код: Redis, Neo4J, CouchDB, MongoDB, HBase, PostgreSQL и Riak. За всяка база са дадени примери за работа с реални данни, демонстриращи основните идеи и силни страни.
Тази книга ще хвърли светлина върху силните и слабите страни на всяка от седемте бази данни и ще ви научи как да изберете тази, която най-добре отговаря на вашите нужди.

• Урок

За какво е този урок?

Този урок е нещо като „печат на моята памет“ на езика SQL (DDL, DML), т.е. Това е информация, която се е натрупала в хода на професионалната ми дейност и постоянно се съхранява в главата ми. Това е за мен достатъчен минимум, който се използва най-често при работа с бази данни. Ако има нужда от използване на по-пълни SQL конструкции, тогава обикновено се обръщам за помощ към библиотеката MSDN, намираща се в Интернет. Според мен е много трудно да държиш всичко в главата си и няма особена нужда от това. Но познаването на основните структури е много полезно, защото... те са приложими в почти същата форма в много релационни бази данни, като Oracle, MySQL, Firebird. Разликите са главно в типовете данни, които могат да се различават в детайлите. Няма много основни SQL конструкции и с постоянна практика те бързо се запомнят. Например, за да създавате обекти (таблици, ограничения, индекси и т.н.), е достатъчно да имате под ръка среда за текстов редактор (IDE) за работа с базата данни и няма нужда да изучавате визуални инструменти, пригодени за работа с специфичен тип база данни (MS SQL, Oracle, MySQL, Firebird, ...). Това също е удобно, защото целият текст е пред очите ви и не е необходимо да преминавате през множество раздели, за да създадете например индекс или ограничение. Когато непрекъснато работите с база данни, създаването, промяната и особено повторното създаване на обект с помощта на скриптове е многократно по-бързо, отколкото ако го правите във визуален режим. Също така в режим на скрипт (и съответно с необходимото внимание) е по-лесно да зададете и контролирате правилата за именуване на обекти (мое субективно мнение). В допълнение, скриптовете са удобни за използване, когато промените, направени в една база данни (например тест), трябва да бъдат прехвърлени в същата форма в друга база данни (продуктивна).

Езикът SQL е разделен на няколко части, тук ще разгледам 2-те най-важни части:

• DML – език за манипулиране на данни, който съдържа следните конструкции:
  • SELECT – избор на данни
  • INSERT – въвеждане на нови данни
  • UPDATE – актуализация на данните
  • DELETE – изтриване на данни
  • MERGE – обединяване на данни

защото Аз съм практик; в този учебник ще има малко теория като такава и всички конструкции ще бъдат обяснени с помощта на практически примери. Освен това вярвам, че езикът за програмиране и особено SQL може да се овладее само чрез практика, като го изпитате сами и разберете какво се случва, когато изпълните тази или онази конструкция.

Този учебник е създаден на принципа Стъпка по стъпка, т.е. трябва да го прочетете последователно и за предпочитане веднага да следвате примерите. Но ако по пътя трябва да научите по-подробно за определена команда, тогава използвайте конкретно търсене в Интернет, например в библиотеката на MSDN.

Когато пишех този урок, използвах базата данни на MS SQL Server версия 2014 и използвах MS SQL Server Management Studio (SSMS), за да изпълня скриптовете.

Накратко за MS SQL Server Management Studio (SSMS)

SQL Server Management Studio (SSMS) е помощна програма за Microsoft SQLСървър за конфигуриране, управление и администриране на компоненти на база данни. Тази помощна програмасъдържа редактор на скриптове (който ще използваме основно) и графична програма, който работи със сървърни обекти и настройки. Основен SQL инструмент Server Management Studio е Object Explorer, който позволява на потребителя да преглежда, извлича и управлява сървърни обекти. Този текст е частично заимстван от Wikipedia.

За да създадете нов редактор на скриптове, използвайте бутона „Нова заявка“:

За да промените текущата база данни, можете да използвате падащия списък:

За да изпълните конкретна команда (или група от команди), изберете я и натиснете бутона „Изпълнение“ или клавиша „F5“. Ако в момента има само една команда в редактора или трябва да изпълните всички команди, тогава не е необходимо да избирате нищо.

След стартиране на скриптове, особено тези, създаващи обекти (таблици, колони, индекси), за да видите промените, използвайте опресняване от контекстно менюкато изберете подходящата група (например Таблици), самата таблица или групата Колони в нея.

Всъщност това е всичко, което трябва да знаем, за да завършим дадените тук примери. Останалата част от помощната програма SSMS е лесна за научаване сами.

Малко теория

Релационна база данни (RDB, или по-долу в контекста просто DB) е колекция от таблици, свързани помежду си. Грубо казано, базата данни е файл, в който данните се съхраняват в структуриран вид.

СУБД – Система за управление на бази данни, т.е. това е набор от инструменти за работа с определен тип база данни (MS SQL, Oracle, MySQL, Firebird, ...).

Забележка
защото в живота, в разговорната реч, най-често казваме: „Oracle DB“, или дори само „Oracle“, всъщност означавайки „Oracle DBMS“, тогава в контекста на този учебник понякога ще се използва терминът DB. От контекста мисля, че ще стане ясно за какво точно говорим.

Таблицата е колекция от колони. Колоните също могат да се наричат ​​полета или колони; всички тези думи ще се използват като синоними, изразяващи едно и също нещо.

Таблицата е основният обект на RDB; всички RDB данни се съхраняват ред по ред в колоните на таблицата. Редовете и записите също са синоними.

За всяка таблица, както и за нейните колони, са посочени имена, с които впоследствие се осъществява достъп до тях.
Името на обекта (име на таблица, име на колона, име на индекс и др.) в MS SQL може да има максимална дължина от 128 знака.

За справка– в базата данни ORACLE имената на обекти могат да имат максимална дължина от 30 знака. Следователно, за конкретна база данни, трябва да разработите свои собствени правила за именуване на обекти, за да спазите ограничението за броя знаци.

SQL е език, който ви позволява да правите заявки към база данни с помощта на СУБД. В конкретна СУБД езикът SQL може да има специфична реализация (собствен диалект).

DDL и DML са подмножество на езика SQL:

• Езикът DDL се използва за създаване и модифициране на структурата на базата данни, т.е. за създаване/промяна/изтриване на таблици и релации.
• Езикът DML ви позволява да манипулирате таблични данни, т.е. с нейните реплики. Тя ви позволява да избирате данни от таблици, да добавяте нови данни към таблици, както и да актуализирате и изтривате съществуващи данни.

В SQL можете да използвате 2 вида коментари (едноредови и многоредови):

Коментар от един ред
И

/* многоредов коментар */

Всъщност това ще бъде достатъчно за теорията.

DDL – Език за дефиниране на данни

Например, помислете за таблица с данни за служители във форма, позната на човек, който не е програмист:

В този случай колоните на таблицата имат следните наименования: Персонален номер, Пълно име, Дата на раждане, E-mail, Длъжност, Отдел.

Всяка от тези колони може да се характеризира с типа данни, които съдържа:

• Персонален номер – цяло число
• Пълно име – низ
• Дата на раждане - дата
• Имейл – низ
• Позиция - низ
• Отдел - линия

Типът колона е характеристика, която показва какъв тип данни може да съхранява дадена колона.

Като начало ще бъде достатъчно да запомните само следните основни типове данни, използвани в MS SQL:

Значение	Нотация в MS SQL	Описание
Низ с променлива дължина	varchar(N) И nvarchar(N)	Използвайки числото N, можем да посочим максималната възможна дължина на низа за съответната колона. Например, ако искаме да кажем, че стойността на колоната „Име“ може да съдържа максимум 30 знака, тогава трябва да зададем нейния тип на nvarchar(30). Разликата между varchar и nvarchar е, че varchar ви позволява да съхранявате низове в ASCII формат, където един знак заема 1 байт, а nvarchar съхранява Unicode низове, където всеки знак заема 2 байта. Типът varchar трябва да се използва само ако сте 100% сигурни, че полето няма да има нужда да съхранява Unicode знаци. Например varchar може да се използва за съхраняване на имейл адреси, защото... те обикновено съдържат само ASCII знаци.
Низ с фиксирана дължина	знак (N) И nchar(N)	Този тип се различава от низ с променлива дължина по това, че ако дължината на низа е по-малка от N знака, тогава той винаги се допълва отдясно до дължина N с интервали и се съхранява в базата данни в тази форма, т.е. в базата данни заема точно N символа (където един знак заема 1 байт за char и 2 байта за nchar). В моята практика този тип се използва много рядко, а ако се използва, то се използва предимно във формат char(1), т.е. когато едно поле е определено от един знак.
Цяло число	вътр	Този тип ни позволява да използваме само цели числа в колоната, както положителни, така и отрицателни. За справка (сега това не е толкова актуално за нас) - диапазон от числа, който позволява int тип-2 147 483 648 до 2 147 483 647. Обикновено това е основният тип, използван за указване на идентификатори.
Реално или реално число	плавам	С прости думи, това са числа, които могат да съдържат десетична точка (запетая).
дата	дата	Ако колоната трябва да съхранява само датата, която се състои от три компонента: ден, месец и година. Например 15.02.2014 г. (15 февруари 2014 г.). Този тип може да се използва за колона „Дата на постъпване“, „Дата на раждане“ и др., т.е. в случаите, когато за нас е важно да запишем само датата или когато часовият компонент не е важен за нас и може да бъде отхвърлен или ако не е известен.
време	време	Този тип може да се използва, ако колоната трябва да съхранява само данни за времето, т.е. Часове, минути, секунди и милисекунди. Например 17:38:31.3231603 Например ежедневно „Час на излитане на полета“.
дата и час	Време за среща	Този тип ви позволява да запазвате едновременно дата и час. Например 02/15/2014 17:38:31.323 Например, това може да са датата и часът на събитие.
Флаг	малко	Този тип е удобен за използване за съхраняване на стойности във формата „Да“/„Не“, където „Да“ ще се съхранява като 1, а „Не“ ще се съхранява като 0.

Освен това стойността на полето, ако не е забранена, може да не бъде посочена; за тази цел се използва ключовата дума NULL.

За да изпълним примерите, нека създадем тестова база данни, наречена Test.

Проста база данни (без посочване на допълнителни параметри) може да бъде създадена чрез изпълнение на следната команда:

СЪЗДАВАНЕ НА БАЗА ДАННИ Тест
Можете да изтриете базата данни с командата (трябва да сте много внимателни с тази команда):

DROP DATABASE Тест
За да преминете към нашата база данни, можете да изпълните командата:

ИЗПОЛЗВАЙТЕ Тест
Друга възможност е да изберете тестовата база данни от падащия списък в областта на менюто на SSMS. Когато работя, често използвам този метод за превключване между бази данни.

Сега в нашата база данни можем да създадем таблица, използвайки описанията такива, каквито са, използвайки интервали и знаци на кирилица:

СЪЗДАВАНЕ НА ТАБЛИЦА [Служители]([Номер на персонала] int, [Име] nvarchar(30), [Дата на раждане] date, nvarchar(30), [Позиция] nvarchar(30), [Отдел] nvarchar(30))
В този случай ще трябва да поставим имената в квадратни скоби […].

Но в базата данни за по-голямо удобство е по-добре да посочите всички имена на обекти на латиница и да не използвате интервали в имената. В MS SQL в този случай обикновено всяка дума започва с Главна буква, например, за полето „Personnel Number“ можем да зададем името PersonnelNumber. Можете също да използвате числа в името, например PhoneNumber1.

На бележка
В някои СУБД следният формат за именуване „PHONE_NUMBER“ може да бъде по-предпочитан; например този формат често се използва в базата данни ORACLE. Естествено, при посочване на име на поле е желателно то да не съвпада с ключовите думи, използвани в СУБД.

Поради тази причина можете да забравите за синтаксиса с квадратни скобии изтрийте таблицата [Служители]:

ПУСКАНЕ НА ТАБЛИЦА [Служители]
Например, таблица със служители може да бъде наречена „Служители“, а полетата й могат да получат следните имена:

• ID – Персонален номер (Employee ID)
• Име - пълно име
• Рожден ден – Дата на раждане
• Имейл – имейл
• Позиция - Позиция
• Отдел - отдел

Много често думата ID се използва за назоваване на поле за идентификатор.

Сега нека създадем нашата таблица:

СЪЗДАВАНЕ НА ТАБЛИЦА Служители (ID int, Име nvarchar(30), Рождена дата, Имейл nvarchar(30), Позиция nvarchar(30), Отдел nvarchar(30))
За да посочите необходимите колони, можете да използвате опцията NOT NULL.

За съществуваща таблица полетата могат да бъдат предефинирани с помощта на следните команди:

Актуализиране на ID поле ALTER TABLE Служители ALTER COLUMN ID int NOT NULL -- актуализиране на име поле ALTER TABLE Служители ALTER COLUMN Име nvarchar(30) NOT NULL

На бележка
Общата концепция на езика SQL остава същата за повечето СУБД (поне това мога да преценя от СУБД, с които съм работил). Разликите между DDL в различните СУБД се състоят главно в типовете данни (тук могат да се различават не само имената им, но и детайлите на тяхното изпълнение), а самата специфика на изпълнението на езика SQL също може да се различава леко (т.е. същността на командите е същата, но може да има малки разлики в диалекта, уви, но няма един стандарт). След като сте усвоили основите на SQL, можете лесно да превключвате от една СУБД към друга, защото... В този случай ще трябва само да разберете подробностите за изпълнението на командите в новата СУБД, т.е. в повечето случаи е достатъчно просто да се направи аналогия.

Създаване на таблица CREATE TABLE Employees(ID int, -- в ORACLE типът int е еквивалент (обвивка) за number(38) Име nvarchar2(30), -- nvarchar2 в ORACLE е еквивалентен на nvarchar в MS SQL Рожден ден, имейл nvarchar2(30), Позиция nvarchar2(30), Отдел nvarchar2(30)); -- актуализиране на полетата ID и Name (тук се използва MODIFY(...) вместо ALTER COLUMN) ALTER TABLE Employees MODIFY(ID int NOT NULL,Name nvarchar2(30) NOT NULL); -- добавяне на PK (в този случай конструкцията изглежда същата като в MS SQL, ще бъде показана по-долу) ALTER TABLE Employees ADD CONSTRAINT PK_Employees PRIMARY KEY(ID);
За ORACLE има разлики по отношение на реализацията на типа varchar2; неговото кодиране зависи от настройките на базата данни и текстът може да бъде записан, например, в UTF-8 кодиране. В допълнение, дължината на полето в ORACLE може да бъде посочена както в байтове, така и в знаци; за това се използват допълнителни опции BYTE и CHAR, които се посочват след дължината на полето, например:

NAME varchar2(30 BYTE) -- капацитетът на полето ще бъде 30 байта NAME varchar2 (30 CHAR) -- капацитетът на полето ще бъде 30 знака
Коя опция ще се използва по подразбиране BYTE или CHAR, в случай на проста индикация в Тип ORACLE varchar2(30), зависи от настройките на базата данни, понякога може да бъде посочен и в IDE настройки. По принцип понякога можете лесно да се объркате, така че в случая на ORACLE, ако се използва тип varchar2 (и това понякога е оправдано тук, например, когато се използва UTF-8 кодиране), предпочитам изрично да напиша CHAR (тъй като обикновено е по-удобно да се изчисли дължината на низа в символи).

Но в този случай, ако в таблицата вече има някакви данни, тогава за успешното изпълнение на командите е необходимо полетата ID и Name да бъдат попълнени във всички редове на таблицата. Нека демонстрираме това с пример: вмъкнете данни в таблицата в полетата ID, Position и Department; това може да стане със следния скрипт:

INSERT Employees(ID,Position,Department) VALUES (1000,N"Директор",N"Администрация"), (1001,N"Програмист",N"ИТ"), (1002,N"Счетоводител",N"Счетоводство" ), (1003,N"Старши програмист",N"IT")
В този случай командата INSERT също ще генерира грешка, тъй като При вмъкването не сме посочили стойността на задължителното поле Име.
Ако вече имахме тези данни в оригиналната таблица, тогава командата „ALTER TABLE Employees ALTER COLUMN ID int NOT NULL“ ще бъде изпълнена успешно и командата „ALTER TABLE Employees ALTER COLUMN Name int NOT NULL“ ще доведе до съобщение за грешка, че полето Име съдържа NULL (неуточнени) стойности.

Нека добавим стойности за полето Име и отново да попълним данните:

Можете също да използвате опцията NOT NULL директно, когато създавате нова маса, т.е. в контекста на командата CREATE TABLE.

Първо изтрийте таблицата с помощта на командата:

DROP TABLE Служители
Сега нека създадем таблица с необходимите колони ID и Name:

CREATE TABLE Employees(ID int NOT NULL, Име nvarchar(30) NOT NULL, Дата на рожден ден, Имейл nvarchar(30), Позиция nvarchar(30), Отдел nvarchar(30))
Можете също да напишете NULL след името на колоната, което ще означава, че в нея ще бъдат разрешени NULL стойности (непосочени), но това не е необходимо, тъй като тази характеристикасе подразбира по подразбиране.

Ако, напротив, искате да направите съществуваща колона незадължителна, използвайте следния команден синтаксис:

ALTER TABLE Служители ALTER COLUMN Име nvarchar(30) NULL
Или просто:

ALTER TABLE Служители ALTER COLUMN Име nvarchar(30)
С тази команда можем също да променим типа на полето на друг съвместим тип или да променим неговата дължина. Например, нека разширим полето Име до 50 знака:

ALTER TABLE Служители ALTER COLUMN Име nvarchar(50)

Първичен ключ

Когато създавате таблица, е желателно тя да има уникална колона или набор от колони, които са уникални за всеки от нейните редове - един запис може да бъде уникално идентифициран чрез тази уникална стойност. Тази стойност се нарича първичен ключ на таблицата. За нашата таблица Служители такава уникална стойност може да бъде колоната ID (която съдържа „Номер на персонала на служителя“ - въпреки че в нашия случай тази стойност е уникална за всеки служител и не може да се повтаря).

Можете да създадете първичен ключ към съществуваща таблица с помощта на командата:

ALTER TABLE Employees ADD CONSTRAINT PK_Employees PRIMARY KEY(ID)
Където "PK_Employees" е името на ограничението, отговорно за първичния ключ. Обикновено първичният ключ се наименува с помощта на префикса „PK_“, последван от името на таблицата.

Ако първичният ключ се състои от няколко полета, тогава тези полета трябва да бъдат изброени в скоби, разделени със запетаи:

ALTER TABLE table_name ADD CONSTRAINT table_name ОСНОВНИ ограничения KEY(поле1,поле2,…)
Струва си да се отбележи, че в MS SQL всички полета, които са включени в първичния ключ, трябва да имат характеристиката NOT NULL.

Първичният ключ може да се определи и директно при създаване на таблица, т.е. в контекста на командата CREATE TABLE. Нека изтрием таблицата:

DROP TABLE Служители
И тогава ще го създадем, използвайки следния синтаксис:

CREATE TABLE Employees(ID int NOT NULL, Name nvarchar(30) NOT NULL, Birthday date, Email nvarchar(30), Position nvarchar(30), Department nvarchar(30), CONSTRAINT PK_Employees PRIMARY KEY(ID) -- опишете PK след всички полета като ограничение)
След създаването попълнете таблицата с данни:

INSERT Employees(ID,Position,Department,Name) VALUES (1000,N"Директор",N"Администрация",N"Иванов И.И."), (1001,N"Програмист",N"ИТ",N" Петров П.П." ), (1002,N"Счетоводител",N"Счетоводство",N"Сидоров С.С."), (1003,N"Старши програмист",N"ИТ",N"Андреев А.А.")
Ако първичният ключ в таблица се състои само от стойностите на една колона, тогава можете да използвате следния синтаксис:

CREATE TABLE Employees(ID int NOT NULL CONSTRAINT PK_Employees PRIMARY KEY, -- посочете като характеристика на полето Име nvarchar(30) NOT NULL, Рождена дата, Имейл nvarchar(30), Позиция nvarchar(30), Отдел nvarchar(30) )
Всъщност не е нужно да указвате името на ограничението, в който случай ще му бъде присвоено име на системата (като „PK__Employee__3214EC278DA42077“):

CREATE TABLE Employees(ID int NOT NULL, Име nvarchar(30) NOT NULL, Дата на рожден ден, Имейл nvarchar(30), Позиция nvarchar(30), Отдел nvarchar(30), PRIMARY KEY(ID))
Или:

CREATE TABLE Employees(ID int NOT NULL PRIMARY KEY, Име nvarchar(30) NOT NULL, Рождена дата, Имейл nvarchar(30), Позиция nvarchar(30), Отдел nvarchar(30))
Но бих препоръчал за постоянните таблици винаги изрично да задавате името на ограничението, защото С изрично посочено и разбираемо име ще бъде по-лесно да го манипулирате по-късно; например можете да го изтриете:

ALTER TABLE Служители DROP CONSTRAINT PK_Employees
Но такъв кратък синтаксис, без да се уточняват имената на ограниченията, е удобен за използване при създаване на временни таблици на база данни (името на временната таблица започва с # или ##), които ще бъдат изтрити след употреба.

Нека да обобщим

Досега разгледахме следните команди:

• СЪЗДАВАНЕ НА ТАБЛИЦА table_name (изброяване на полета и техните типове, ограничения) – използва се за създаване на нова таблица в текущата база данни;
• ПАДВАЩА МАСА table_name – използва се за изтриване на таблица от текущата база данни;
• АЛТЕР ТАБЛИЦАиме_на_таблица ПРОМЯНА НА КОЛОНАТА column_name... – използва се за актуализиране на типа на колоната или за промяна на нейните настройки (например за задаване на характеристиката NULL или NOT NULL);
• АЛТЕР ТАБЛИЦАиме_на_таблица ДОБАВЯНЕ НА ОГРАНИЧЕНИЕиме_на_ограничение ПЪРВИЧЕН КЛЮЧ(поле1, поле2,...) – добавяне на първичен ключ към съществуваща таблица;
• АЛТЕР ТАБЛИЦАиме_на_таблица ОТПУСКАНЕ НА ОГРАНИЧЕНИЕ constraint_name – премахва ограничение от таблицата.

Малко за временните маси

Извлечение от MSDN.В MS SQL Server има два типа временни таблици: локални (#) и глобални (##). Локалните временни таблици са видими само за техните създатели, докато сесията за свързване към екземпляра на SQL Server приключи, когато са създадени за първи път. Локалните временни таблици се изтриват автоматично, след като потребителят прекъсне връзката с екземпляра на SQL Server. Глобалните временни таблици са видими за всички потребители по време на всяка сесия на връзка след създаването на тези таблици и се изтриват, когато всички потребители, препращащи към тези таблици, прекъснат връзката с екземпляра на SQL Server.

В системата се създават временни таблици tempdb база данни, т.е. Създавайки ги, ние не задръстваме основната база данни; в противен случай временните таблици са напълно идентични с обикновените таблици; те също могат да бъдат изтрити с помощта на командата DROP TABLE. По-често се използват локални (#) временни таблици.

За да създадете временна таблица, можете да използвате командата CREATE TABLE:

СЪЗДАВАНЕ НА ТАБЛИЦА #Temp(ID int, име nvarchar(30))
Тъй като временната таблица в MS SQL е подобна на обикновена таблица, тя може да бъде изтрита и с помощта на командата DROP TABLE:

ТАБЛИЦА ЗА ПАДАНЕ #Темп

Можете също така да създадете временна таблица (като обикновена таблица) и веднага да я попълните с данните, върнати от заявката, като използвате синтаксиса SELECT ... INTO:

ИЗБЕРЕТЕ ИДЕНТИФИКАТОР, Име В #Врем. ОТ Служители

На бележка
Реализацията на временни таблици може да се различава в различните СУБД. Например в СУБД ORACLE и Firebird структурата на временните таблици трябва да бъде определена предварително чрез командата CREATE GLOBAL TEMPORARY TABLE, като се посочва спецификата на съхраняване на данни в нея, след което потребителят я вижда сред основните таблици и работи с нея както при обикновена маса.

Нормализация на базата данни – разделяне на подтаблици (директории) и идентифициране на връзки

Нашата текуща таблица Служители има недостатъка, че в полетата Позиция и Отдел потребителят може да въведе произволен текст, който е изпълнен предимно с грешки, тъй като за един служител той може просто да посочи „ИТ“ като отдел, а за втори служител, за например, въведете „ИТ отдел“, третият има „ИТ“. В резултат на това ще бъде неясно какво е имал предвид потребителят, т.е. Тези служители служители ли са в един и същи отдел или потребителят се е описал и това са 3 различни отдела? Освен това в този случай няма да можем да групираме правилно данните за някакъв отчет, където може да е необходимо да се покаже броят на служителите по всеки отдел.

Вторият недостатък е обемът на съхранение на тази информация и нейното дублиране, т.е. За всеки служител е посочено пълното име на отдела, което изисква място в базата данни за съхраняване на всеки знак от името на отдела.

Третият недостатък е трудността при актуализиране на тези полета, ако името на позиция се промени, например, ако трябва да преименувате позицията „Програмист“ на „Младши програмист“. В този случай ще трябва да направим промени във всеки ред от таблицата, чиято позиция е равна на „Програмист“.

За да се избегнат тези недостатъци, се използва т. нар. нормализиране на базата данни - разделянето й на подтаблици и справочни таблици. Не е необходимо да навлизате в джунглата на теорията и да изучавате какво представляват нормалните форми, достатъчно е да разберете същността на нормализацията.

Нека създадем 2 таблици с директории „Позиции“ и „Отдели“, нека наречем първата позиция, а втората съответно отдели:

CREATE TABLE Positions(ID int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Positions PRIMARY KEY, Name nvarchar(30) NOT NULL) CREATE TABLE Departments(ID int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Departments PRIMARY KEY, Name nvarchar(30) ) НЕ NULL)
Имайте предвид, че тук използвахме новата опция IDENTITY, която казва, че данните в колоната ID ще бъдат номерирани автоматично, започвайки от 1, на стъпки от 1, т.е. При добавяне на нови записи, те ще бъдат последователно присвоени стойностите 1, 2, 3 и т.н. Такива полета обикновено се наричат ​​автоматично нарастващи. Една таблица може да има само едно поле, дефинирано със свойството IDENTITY, и обикновено, но не непременно, това поле е първичният ключ за тази таблица.

На бележка
В различните СУБД реализацията на полета с брояч може да се извърши по различен начин. В MySQL, например, такова поле се дефинира с помощта на опцията AUTO_INCREMENT. В ORACLE и Firebird тази функционалност можеше да бъде емулирана преди с помощта на SEQUENCE. Но доколкото знам, ORACLE вече е добавил опцията GENERATED AS IDENTITY.

Нека попълним тези таблици автоматично, въз основа на текущите данни, записани в полетата Позиция и Отдел на таблицата Служители:

Попълваме полето Name на таблицата Positions с уникални стойности от полето Position на таблицата Employees INSERT Positions(Name) SELECT DISTINCT Position FROM Employees WHERE Position IS NOT NULL -- отхвърляне на записи, за които позицията не е посочена
Нека направим същото за таблицата Departments:

INSERT Departments (Name) SELECT DISTINCT Department FROM Employees WHERE Department IS NOT NULL
Ако сега отворим таблиците с позиции и отдели, ще видим номериран набор от стойности за полето ID:

ИЗБЕРЕТЕ * ОТ позиции

ИЗБЕРЕТЕ * ОТ отдели

Тези таблици вече ще играят ролята на справочници за уточняване на позиции и отдели. Сега ще се позоваваме на идентификационни номера на работа и отдел. Първо, нека създадем нови полета в таблицата Employees, за да съхраняваме идентификационни данни:

Добавете поле за ID на позиция ALTER TABLE Служители ADD PositionID int -- добавете поле за ID на отдел ALTER TABLE Служители ADD DepartmentID int
Типът на референтните полета трябва да е същият като в директориите, в този случай е int.

Можете също така да добавите няколко полета към таблицата наведнъж с една команда, изброявайки полетата, разделени със запетаи:

ALTER TABLE Служители ADD PositionID int, DepartmentID int
Сега нека напишем връзки (референтни ограничения - FOREIGN KEY) за тези полета, така че потребителят да няма възможност да напише в тези полета стойности, които не са сред стойностите на ID, намерени в директориите.

ALTER TABLE Employees ADD CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) РЕФЕРЕНЦИИ Positions(ID)
И ще направим същото за второто поле:

ALTER TABLE Employees ADD CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERENCES Departments(ID)
Сега потребителят ще може да въвежда само ID стойности от съответната директория в тези полета. Съответно, за да използва нов отдел или позиция, той първо трябва да добави нов запис в съответната директория. защото Длъжностите и отделите вече се съхраняват в директории в едно копие, така че за да промените името, е достатъчно да го промените само в директорията.

Името на референтно ограничение обикновено е съставно име, състоящо се от префикса "FK_", последвано от името на таблицата и последвано от долна черта, последвано от името на полето, което се отнася до идентификатора на референтната таблица.

Идентификаторът (ID) обикновено е вътрешна стойност, която се използва само за връзки и каква стойност се съхранява там е напълно безразлично в повечето случаи, така че няма нужда да се опитвате да се отървете от дупките в последователността от числа, които възникват по време на работа с таблицата, например, след изтриване на записи от директорията.

ALTER TABLE table ADD CONSTRAINT име на_ограничение FOREIGN KEY(field1,field2,…) REFERENCES reference_table(field1,field2,…)
В този случай в таблицата “reference_table” първичният ключ е представен от комбинация от няколко полета (field1, field2,...).

Всъщност, сега нека актуализираме полетата PositionID и DepartmentID с ID стойности от директориите. Нека използваме командата DML UPDATE за тази цел:

UPDATE e SET PositionID=(SELECT ID FROM Positions WHERE Name=e.Position), DepartmentID=(SELECT ID FROM Departments WHERE Name=e.Department) FROM Employees e
Да видим какво ще се случи, като изпълним заявката:

ИЗБЕРЕТЕ * ОТ Служители

Това е всичко, полетата PositionID и DepartmentID се попълват с идентификаторите, съответстващи на длъжности и отдели; полетата Position и Department вече не са необходими в таблицата Employees, можете да изтриете тези полета:

ALTER TABLE Служители DROP COLUMN Позиция, отдел
Сега нашата таблица изглежда така:

ИЗБЕРЕТЕ * ОТ Служители

документ за самоличност	Име	рожден ден	електронна поща	PositionID	ИД на отдел
1000	Иванов И.И.	НУЛА	НУЛА	2	1
1001	Петров П.П.	НУЛА	НУЛА	3	3
1002	Сидоров С.С.	НУЛА	НУЛА	1	2
1003	Андреев А.А.	НУЛА	НУЛА	4	3

Тези. В крайна сметка се отървахме от съхраняването на излишна информация. Сега, въз основа на номерата на работата и отдела, можем недвусмислено да определим техните имена, като използваме стойностите в референтните таблици:

SELECT e.ID,e.Name,p.Name PositionName,d.Name DepartmentName FROM Служители e LEFT JOIN Отдели d ON d.ID=e.DepartmentID LEFT JOIN Позиции p ON p.ID=e.PositionID

В инспектора на обекти можем да видим всички обекти, създадени за дадена таблица. От тук можете да извършвате различни манипулации с тези обекти - например да преименувате или изтривате обекти.

Също така си струва да се отбележи, че таблицата може да се отнася до себе си, т.е. можете да създадете рекурсивна връзка. Например, нека добавим още едно поле ManagerID към нашата таблица със служители, което ще посочи служителя, на когото този служител докладва. Нека създадем поле:

ALTER TABLE Служители ADD ManagerID int
Това поле позволява стойност NULL; полето ще бъде празно, ако например няма началници над служителя.

Сега нека създадем FOREIGN KEY за таблицата Employees:

ALTER TABLE Employees ADD CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) REFERENCES Employees(ID)
Нека сега създадем диаграма и да видим как изглеждат връзките между нашите таблици върху нея:

В резултат на това трябва да видим следната картина (таблицата Employees е свързана с таблиците Positions и Depertments и също се отнася за себе си):

И накрая, струва си да се каже, че референтните ключове могат да включват допълнителни опции НА ИЗТРИВАНЕ НА КАСКАДА и НА АКТУАЛИЗИРАНЕ НА КАСКАДА, които показват как да се държите при изтриване или актуализиране на запис, който е посочен в референтната таблица. Ако тези опции не са зададени, тогава не можем да променим идентификатора в таблицата на директорията за запис, който е препратен от друга таблица, и също така няма да можем да изтрием такъв запис от директорията, докато не изтрием всички редове, препращащи към този запис или, нека актуализираме препратките в тези редове до различна стойност.

Например, нека пресъздадем таблицата, указваща опцията ON DELETE CASCADE за FK_Employees_DepartmentID:

DROP TABLE Employees CREATE TABLE Employees(ID int NOT NULL, Name nvarchar(30), Birthday date, Email nvarchar(30), PositionID int, DepartmentID int, ManagerID int, CONSTRAINT PK_Employees PRIMARY KEY (ID), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID ) REFERENCES Departments(ID) ON DELETE CASCADE, CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERENCES Positions(ID), CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) REFERENCES Employees(ID)) INSERT Employees (ID,Name,Birthday, ИД на позиция, ИД на отдел, ИД на мениджър ) СТОЙНОСТИ (1000,N"Ivanov I.I.","19550219",2,1,NULL), (1001,N"Petrov P.P.","19831203",3,3,1003), (1002 ,N"Sidorov S.S." ,"19760607",1,2,1000), (1003,N"Андреев А.А.","19820417",4,3,1000)
Нека изтрием отдела с ID 3 от таблицата с отдели:

DELETE Departments WHERE ID=3
Нека да разгледаме данните в таблицата Служители:

ИЗБЕРЕТЕ * ОТ Служители

документ за самоличност	Име	рожден ден	електронна поща	PositionID	ИД на отдел	ИД на мениджър
1000	Иванов И.И.	1955-02-19	НУЛА	2	1	НУЛА
1002	Сидоров С.С.	1976-06-07	НУЛА	1	2	1000

Както можете да видите, данните за отдел 3 от таблицата Служители също бяха изтрити.

Опцията ON UPDATE CASCADE се държи по подобен начин, но е ефективна при актуализиране на стойността на ID в директорията. Например, ако променим идентификатора на позиция в директорията на позициите, тогава в този случай идентификаторът на отдел в таблицата Служители ще бъде актуализиран до новата стойност на идентификатора, която сме задали в директорията. Но в този случай просто няма да е възможно да се демонстрира това, защото колоната ID в таблицата Departments има опция IDENTITY, която няма да ни позволи да изпълним следната заявка (променете ID на отдел 3 на 30):

АКТУАЛИЗИРАНЕ на отдели SET ID=30 WHERE ID=3
Основното нещо е да разберете същността на тези 2 опции ON DELETE CASCADE и ON UPDATE CASCADE. Използвам тези опции много рядко и ви препоръчвам да помислите внимателно, преди да ги посочите в референтно ограничение, т.к ако случайно изтриете запис от таблица с директории, това може да доведе до големи проблеми и да предизвика верижна реакция.

Нека възстановим отдел 3:

Даваме разрешение за добавяне/промяна на IDENTITY стойност SET IDENTITY_INSERT Отдели ON INSERT Отдели(ID,Име) VALUES(3,N"IT") -- забраняваме добавянето/промяна на IDENTITY стойност SET IDENTITY_INSERT Отдели ИЗКЛ.
Нека изчистим напълно таблицата Employees с помощта на командата TRUNCATE TABLE:

СЪРЪЗНАТА ТАБЛИЦА Служители
И отново ще презаредим данните в него, като използваме предишната команда INSERT:

INSERT Employees (ID,Name,Birthday,PositionID,DepartmentID,ManagerID)VALUES (1000,N"Ivanov I.I.","19550219",2,1,NULL), (1001,N"Petrov P.P." ,"19831203",3 ,3,1003), (1002,N"Сидоров С.С.","19760607",1,2,1000), (1003,N"Андреев А.А.","19820417" ,4,3,1000)

Нека да обобщим

В момента към нашето знание са добавени още няколко DDL команди:

• Добавяне на свойството IDENTITY към поле – позволява ви да направите това поле автоматично попълвано поле (поле за брояч) за таблицата;
• АЛТЕР ТАБЛИЦАиме_на_таблица ДОБАВЯНЕ list_of_fields_with_characteristics – позволява добавяне на нови полета към таблицата;
• АЛТЕР ТАБЛИЦАиме_на_таблица ПУСКАНЕ НА КОЛОНА list_fields – позволява премахване на полета от таблицата;
• АЛТЕР ТАБЛИЦАиме_на_таблица ДОБАВЯНЕ НА ОГРАНИЧЕНИЕиме_на_ограничение ВЪНШЕН КЛЮЧ(полета) ПРЕПРАТКИ table_reference (полета) – позволява ви да дефинирате връзката между таблицата и референтната таблица.

Други ограничения – УНИКАЛНО, ПО ПОДРАЗБИРАНЕ, ПРОВЕРКА

Използвайки ограничение UNIQUE, можете да кажете, че стойността за всеки ред в дадено поле или набор от полета трябва да бъде уникална. В случая на таблицата Employees можем да наложим такова ограничение на полето Email. Просто попълнете предварително имейл със стойности, ако те още не са дефинирани:

АКТУАЛИЗИРАНЕ НА Служители SET Email=" [имейл защитен]" WHERE ID=1000 UPDATE Employees SET Email=" [имейл защитен]" WHERE ID=1001 UPDATE Employees SET Email=" [имейл защитен]" WHERE ID=1002 UPDATE Employees SET Email=" [имейл защитен]„WHERE ID=1003
Сега можете да наложите ограничение за уникалност на това поле:

ALTER TABLE Служители ДОБАВЯНЕ НА ОГРАНИЧЕНИЕ UQ_Employees_Email UNIQUE(Имейл)
Сега потребителят няма да може да въвежда една и съща електронна поща за няколко служители.

Уникалното ограничение обикновено се наименува по следния начин – първо идва префиксът “UQ_”, след това името на таблицата и след долната черта идва името на полето, върху което се прилага това ограничение.

Съответно, ако комбинация от полета трябва да бъде уникална в контекста на редовете на таблицата, тогава ние ги изброяваме разделени със запетаи:

ALTER TABLE table_name ADD CONSTRAINT constraint_name UNIQUE(поле1,поле2,…)
Като добавим ограничение DEFAULT към полето, можем да зададем стойност по подразбиране, която ще бъде заменена, ако при вмъкване нов входтова поле няма да бъде посочено в списъка с полета на командата INSERT. Това ограничение може да бъде зададено директно при създаването на таблицата.

Нека добавим ново поле за дата на наемане към таблицата Служители и да го наречем HireDate и да кажем, че стойността по подразбиране за това поле ще бъде текущата дата:

ALTER TABLE Служители ADD HireDate date NOT NULL DEFAULT SYSDATETIME()
Или ако колоната HireDate вече съществува, тогава може да се използва следният синтаксис:

ALTER TABLE Служители ДОБАВЯНЕ ПО ПОДРАЗБИРАНЕ SYSDATETIME() ЗА HireDate
Тук не посочих името на ограничението, защото... в случай на DEFAULT смятам, че това не е толкова критично. Но ако го направите по добър начин, тогава мисля, че не е нужно да сте мързеливи и трябва да зададете нормално име. Това се прави по следния начин:

ALTER TABLE Employees ADD CONSTRAINT DF_Employees_HireDate ПО ПОДРАЗБИРАНЕ SYSDATETIME() ЗА HireDate
Тъй като тази колона не е съществувала преди, когато се добави към всеки запис, стойността на текущата дата ще бъде вмъкната в полето HireDate.

При добавяне на нов запис текущата дата също ще бъде вмъкната автоматично, разбира се, освен ако не сме я задали изрично, т.е. Няма да го посочим в списъка с колони. Нека покажем това с пример, без да посочваме полето HireDate в списъка с добавени стойности:

INSERT Employees(ID,Name,Email)VALUES(1004,N"Sergeev S.S."," [имейл защитен]")
Да видим какво се случи:

ИЗБЕРЕТЕ * ОТ Служители

документ за самоличност	Име	рожден ден	електронна поща	PositionID	ИД на отдел	ИД на мениджър	Дата на наемане
1000	Иванов И.И.	1955-02-19	[имейл защитен]	2	1	НУЛА	2015-04-08
1001	Петров П.П.	1983-12-03	[имейл защитен]	3	4	1003	2015-04-08
1002	Сидоров С.С.	1976-06-07	[имейл защитен]	1	2	1000	2015-04-08
1003	Андреев А.А.	1982-04-17	[имейл защитен]	4	3	1000	2015-04-08
1004	Сергеев С.С.	НУЛА	[имейл защитен]	НУЛА	НУЛА	НУЛА	2015-04-08

Ограничението за проверка CHECK се използва, когато е необходимо да се проверят стойностите, въведени в поле. Например, нека наложим това ограничение върху полето за персонален номер, което за нас е идентификатор на служител (ID). С помощ това ограничениеДа кажем, че номерата на персонала трябва да имат стойност от 1000 до 1999:

ALTER TABLE Employees ADD CONSTRAINT CK_Employees_ID CHECK(ID BETWEEN 1000 AND 1999)
Ограничението обикновено се наименува по същия начин, първо с префикса „CK_“, след това името на таблицата и името на полето, върху което е наложено това ограничение.

Нека се опитаме да вмъкнем невалиден запис, за да проверим дали ограничението работи (трябва да получим съответната грешка):

INSERT Employees(ID,Email) VALUES(2000," [имейл защитен]")
Сега нека променим вмъкнатата стойност на 1500 и се уверете, че записът е вмъкнат:

INSERT Employees(ID,Email) VALUES(1500," [имейл защитен]")
Можете също да създадете UNIQUE и CHECK ограничения, без да посочвате име:

ALTER TABLE Employees ADD UNIQUE(Email) ALTER TABLE Employees ADD CHECK(ID BETWEEN 1000 AND 1999)
Но не е много добра практикаи е по-добре да посочите изрично името на ограничението, т.к За да го разберете по-късно, което ще бъде по-трудно, ще трябва да отворите обекта и да погледнете за какво отговаря.

С добро име много информация за ограничението може да се научи директно от името му.

И съответно всички тези ограничения могат да бъдат създадени веднага при създаването на таблица, ако тя все още не съществува. Нека изтрием таблицата:

DROP TABLE Служители
И ние ще го пресъздадем с всички създадени ограничения с една команда CREATE TABLE:

CREATE TABLE Employees(ID int NOT NULL, Name nvarchar(30), Birthday date, Email nvarchar(30), PositionID int, DepartmentID int, HireDate date NOT NULL DEFAULT SYSDATETIME(), -- за DEFAULT ще направя изключение CONSTRAINT PK_Employees PRIMARY KEY (ID), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERENCES Departments(ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERENCES Positions(ID), CONSTRAINT UQ_Employees_Email UNIQUE (Email), CONSTRAINT CK_Employees _ПРОВЕРКА НА ИД (ID МЕЖДУ 1000 И 1999) )

INSERT Employees (ID,Name,Birthday,Email,PositionID,DepartmentID)VALUES (1000,N"Ivanov I.I.","19550219"," [имейл защитен]",2,1), (1001,N"Петров П.П.","19831203"," [имейл защитен]",3,3), (1002,N"Сидоров С.С.","19760607"," [имейл защитен]",1,2), (1003,N"Андреев А.А.","19820417"," [имейл защитен]",4,3)

Малко за индексите, създадени при създаване на PRIMARY KEY и UNIQUE ограничения

Както можете да видите на екранната снимка по-горе, при създаването на ограниченията PRIMARY KEY и UNIQUE автоматично бяха създадени индекси с еднакви имена (PK_Employees и UQ_Employees_Email). По подразбиране индексът за първичния ключ се създава като CLUSTERED, а за всички останали индекси като NONCLUSTERED. Струва си да се каже, че концепцията за клъстерен индекс не е налична във всички СУБД. Една таблица може да има само един CLUSTERED индекс. CLUSTERED – означава, че записите в таблицата ще бъдат сортирани по този индекс, можем също така да кажем, че този индекс има директен достъп до всички данни в таблицата. Това е основният индекс на таблицата, така да се каже. Казано още по-грубо, това е индекс, прикрепен към таблица. Клъстерираният индекс е много мощен инструмент, който може да помогне с оптимизирането на заявките, но нека просто запомним това засега. Ако искаме да кажем на клъстерирания индекс да се използва не върху първичния ключ, а върху друг индекс, тогава при създаването на първичния ключ трябва да посочим опцията NONCLUSTERED:

ALTER TABLE table_name ADD CONSTRAINT constraint_name PRIMARY KEY NONCLUSTERED(field1,field2,…)
Например, нека направим индекса на ограничението PK_Employees неклъстериран, а индекса на ограничението UQ_Employees_Email - клъстериран. Първо, нека премахнем тези ограничения:

ALTER TABLE Служители DROP CONSTRAINT PK_Employees ALTER TABLE Employees DROP CONSTRAINT UQ_Employees_Email
Сега нека ги създадем с опциите CLUSTERED и NONCLUSTERED:

ALTER TABLE Employees ADD CONSTRAINT PK_Employees PRIMARY KEY NONCLUSTERED (ID) ALTER TABLE Employees ADD CONSTRAINT UQ_Employees_Email UNIQUE CLUSTERED (Email)
Сега, като изберете от таблицата Employees, ще видим, че записите са сортирани по клъстерирания индекс UQ_Employees_Email:

ИЗБЕРЕТЕ * ОТ Служители

документ за самоличност	Име	рожден ден	електронна поща	PositionID	ИД на отдел	Дата на наемане
1003	Андреев А.А.	1982-04-17	[имейл защитен]	4	3	2015-04-08
1000	Иванов И.И.	1955-02-19	[имейл защитен]	2	1	2015-04-08
1001	Петров П.П.	1983-12-03	[имейл защитен]	3	3	2015-04-08
1002	Сидоров С.С.	1976-06-07	[имейл защитен]	1	2	2015-04-08

Преди това, когато клъстерираният индекс беше индексът PK_Employees, записите бяха сортирани по полето ID по подразбиране.

Но в този случай това е само пример, който показва същността на клъстерния индекс, т.к Най-вероятно ще се правят заявки към таблицата Employees, като се използва полето ID и в някои случаи може би самата тя ще действа като директория.

За директории обикновено се препоръчва клъстерният индекс да бъде изграден върху първичния ключ, т.к в заявките често се позоваваме на идентификатора на директорията, за да получим например името (позиция, отдел). Нека си спомним тук какво написах по-горе, че клъстерният индекс има директен достъп до редовете на таблицата и от това следва, че можем да получим стойността на всяка колона без допълнителни разходи.

Благоприятно е да се приложи клъстерен индекс към полета, които се вземат най-често.

Понякога таблиците се създават с ключ, базиран на сурогатно поле; в този случай може да е полезно да запазите опцията за индекс CLUSTERED за по-подходящ индекс и да посочите опцията NONCLUSTERED, когато създавате сурогатен първичен ключ.

Нека да обобщим

На този етап сме се запознали с всички видове ограничения в самата им същност в проста форма, които се създават от команда като „ALTER TABLE table_name ADD CONSTRAINT constraint_name…“:

• ПЪРВИЧЕН КЛЮЧ– първичен ключ;
• ВЪНШЕН КЛЮЧ– създаване на връзки и наблюдение на референтната цялост на данните;
• ЕДИНСТВЕН ПО РОДА СИ– ви позволява да създавате уникалност;
• ПРОВЕРКА– позволява да се гарантира коректността на въведените данни;
• ПО ПОДРАЗБИРАНЕ– позволява ви да зададете стойност по подразбиране;
• Също така си струва да се отбележи, че всички ограничения могат да бъдат премахнати с помощта на командата „ АЛТЕР ТАБЛИЦАиме_на_таблица ОТПУСКАНЕ НА ОГРАНИЧЕНИЕиме_на_ограничение".

Също така частично засегнахме темата за индексите и разгледахме концепцията за клъстер ( КЛУСТЕРИРАН) и негрупирани ( НЕКЛУСТЕРЕН) индекс.

Създаване на самостоятелни индекси

Под независими тук имаме предвид индекси, които не са създадени под ограничението PRIMARY KEY или UNIQUE.

Индекси на поле или полета могат да бъдат създадени със следната команда:

CREATE INDEX IDX_Employees_Name ON Employees(Name)
Също така тук можете да посочите опциите CLUSTERED, NONCLUSTERED, UNIQUE и можете също да посочите посоката на сортиране на всяко отделно поле ASC (по подразбиране) или DESC:

СЪЗДАВАНЕ НА УНИКАЛЕН НЕКЛУСТЕРИРАН ИНДЕКС UQ_Employees_EmailDesc НА Служители(Имейл DESC)
Когато създавате неклъстъриран индекс, опцията NONCLUSTERED може да бъде пропусната, защото това се подразбира по подразбиране и е показано тук просто за да посочи позицията на опцията CLUSTERED или NONCLUSTERED в командата.

Можете да изтриете индекса със следната команда:

DROP INDEX IDX_Employees_Name ON Employees
Прости индекси, както и ограничения, могат да бъдат създадени в контекста на командата CREATE TABLE.

Например, нека изтрием отново таблицата:

DROP TABLE Служители
И ние ще го създадем отново с всички създадени ограничения и индекси с една команда CREATE TABLE:

CREATE TABLE Employees(ID int NOT NULL, Name nvarchar(30), Birthday date, Email nvarchar(30), PositionID int, DepartmentID int, HireDate date NOT NULL CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME(), ManagerID int, CONSTRAINT PK_Employees PRIMARY KEY (ID ), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERENCES Departments(ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERENCES Positions(ID), CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) REFERENCES Employees(ID), ОГРАНИЧЕНИЕ UQ_Emp loyees_Email UNIQUE(Имейл), ОГРАНИЧЕНИЕ CK_Employees_ID CHECK (ИД МЕЖДУ 1000 И 1999), ИНДЕКС IDX_Employees_Name (Име))
И накрая, нека вмъкнем нашите служители в таблицата:

ВМЪКНЕТЕ Служители (ID,Име,Рожден ден,Имейл,ПозицияID,DepartmentID,ManagerID)СТОЙНОСТИ (1000,N"Ivanov I.I.","19550219"," [имейл защитен]",2,1,NULL), (1001,N"Петров П.П.","19831203"," [имейл защитен]",3,3,1003), (1002,N"Сидоров С.С.","19760607"," [имейл защитен]",1,2,1000), (1003,N"Андреев А.А.","19820417"," [имейл защитен]",4,3,1000)
Освен това си струва да се отбележи, че можете да включите стойности в неклъстъриран индекс, като ги посочите в INCLUDE. Тези. в този случай индексът INCLUDE донякъде ще напомня на клъстерен индекс, само сега индексът не е прикрепен към таблицата, но необходимите стойности са прикрепени към индекса. Съответно такива индекси могат значително да подобрят производителността на заявките за избор (SELECT); ако всички изброени полета са в индекса, тогава достъпът до таблицата може изобщо да не е необходим. Но това естествено увеличава размера на индекса, т.к стойностите на изброените полета се дублират в индекса.

Извлечение от MSDN.Общ команден синтаксис за създаване на индекси

СЪЗДАВАЙТЕ [УНИКАЛЕН] [КЛУСТЕРИРАН | NONCLUSTERED ] INDEX index_name ВКЛ