SELECT Explanation, Example FROM Pro.Knowledge
FacebookRSS

Środowisko MS SQL Server

MS SQL Server to System Zarządzania Bazą Danych (SZBD). Najnowsza wersja SQL Server 2017 jest już 14 generacją (zgodnie z oznaczeniami znaczących wersji MS) tego systemu.
Nie wszyscy wiedzą, że początki SQL Server sięgają 1987 roku. Zatem obecnie, mamy do czynienia z produktem którego historia liczy ponad 25 lat. Z punktu widzenia czasu życia produktu, szczególnie w świecie IT to przecież cała wieczność. Możemy więc śmiało stwierdzić, że SQL Server jest dojrzałym produktem.

W artykule tym, znajdziesz ogólne informacje na temat środowiska bazodanowego SQL Server. Kilka słów o historii, dostępnych narzędziach i komponentach.


Historia SQL Server

Zacznijmy jednak od narodzin. W 1987 roku, firma Microsoft wraz Sybase, a później również z Ashton Tate rozpoczęła współpracę biznesową nad produktem serwera bazy danych. Rezultatem była pierwsza wersja produktu – Ashton Tate/Microsoft SQL Server 1.0 wydana w 1989. Od tego czasu przez niemal dekadę, Sybase i Microsoft współpracowali, wydając kolejne wersje systemu. Jeśli miałeś do czynienia z produktami Sybase – znajdziesz wiele podobieństw do SQL Server, chociażby w dialekcie SQL. Być może dlatego, spotkać można teorie, że SQL Server to tak naprawdę produkt Sybase, kupiony w pewnym momencie przez Microsoft, co jednak nie jest prawdą. Więcej informacji na temat historii SQL Server, obalaniu mitów – znajdziesz na blogach Euan Garden oraz Kalen Delaney. Szczególnie polecam historię SQL Server w pigułce w formie foto-posta :)

Od 1989 wydano następujące wersje SQL Server :

Wersja Rok wydania Oficjalna nazwa Projekt
1.0 1989 SQL Server 1.0
1.1 1991 SQL Server 1.1
4.2 1992 SQL Server 4.2
4.21 1994 SQL Server 4.21 SQLNT
6.0 1995 SQL Server 6.0 SQL95
6.5 1996 SQL Server 6.5 Hydra
7.0 1998 SQL Server 7.0 Sphinx
8.0 2000 SQL Server 2000 Shiloh
9.0 2005 SQL Server 2005 Yukon
10.0 2008 SQL Server 2008 Katmai
10.5 2010 SQL Server 2008 R2 Kilimanjaro
11.0 2012 SQL Server 2012 Denali
12.0 2014 SQL Server 2014 Hekaton*
13.0 2016 SQL Server 2016
14.0 2017 SQL Server 2017


Edycje SQL Server

MS SQL Server oferowany jest w różnych edycjach. W zależności od potrzeb, konkretnych funkcjonalności, możemy wybrać z pośród kilku wydań. W praktyce, spotkać się można najczęściej z wersją darmową Express i komercyjnymi – Standard lub w dużych i średnich wdrożeniach – Enterprise (flagowy produkt, najwyższa edycja, ze wszystkimi możliwymi opcjami). Oprócz nich, są jeszcze pośrednie wersje, takie jak Web czy Businness Intelligence, ale są one stosunkowo rzadko spotykane.

Pełne porównanie poszczególnych edycji SQL Server, możliwości, dostępnych komponentów znajdziesz na oficjalnych stronach Microsoft.


Środowisko SQL Server, komponenty

Podstawą platformy SQL Server jest usługa serwera. Realizuje wszystkie zadania związane z obsługą i utrzymaniem baz danych. Jest ona fundamentem i każde wdrożenie, opiera się o trzon silnika bazy danych (Database Engine).

Środowisko SQL Server jest skalowalne i składać się może z wielu komponentów. W zależności od potrzeb i możliwości wybranej edycji, możemy w trakcie instalacji wybierać spośród dostępnych funkcjonalności. Instalacja kompletnego środowiska SQL Server na maszynie fizycznej lub wirtualnej to INSTANCJA. W jej ramach, możemy zarządzać wieloma bazami danych. W SQL Server 2012 jest to maksymalnie aż 32767 baz danych per instancja. Więcej informacji na temat możliwości instancji, ograniczeń znajdziesz tutaj.

Na danym fizycznym (lub wirtualnym) serwerze, możemy zainstalować wiele instancji SQL Server. Są one w pełni niezależne i tworzą odrębne środowiska SQL Server. W praktyce, rzadko spotyka się komercyjne wdrożenia więcej niż dwóch, trzech instancji na maszynie. Podyktowane jest to głównie przez aspekty wydajnościowe – zazwyczaj jest jedna.

Silnik bazy danych

To najważniejszy z komponentów, odpowiedzialny za przetwarzanie zapytań, zarządza składowaniem, ochronie danych. Obsługuje niezbędne mechanizmy bezpieczeństwa, autoryzacji czy autentykacji. Silnik bazy danych jest uruchomiony na serwerze jako usługa, inaczej mówiąc jest to po prostu aplikacja działająca w tle środowiska Windows, obsługująca wszelkie procesy związane z bazami danych.

Usługi analityczne

Jest to tak naprawdę w sumie kilka komponentów z rodziny analitycznej. Analityka (OLAP) , PowerPivot, Data Minning, ogólnie wszystko co związane z Business Intelligence czyli inaczej usługami drążenia danych. Są to w ogólności procesy, mechanizmy, mające na celu przekształcenie danych w informacje a informacje w wiedze. Dzięki nim, możemy szukać zależności między danymi i odkrywać związki.

Usługi analityczne dostarczają mechanizmów raportujących, wydobywających wiedzę, analizując dane pochodzącą z baz transakcyjnych (OLTP). Na jej podstawie możemy wyciągać wnioski, przewidywać pewne zachowania, które mogą wpływać np. wzrost konkurencyjności przedsiębiorstwa.

Usługi raportujące (Reporting Services)

Komponent stworzony z myślą o raportowaniu z baz danych SQL Server. Nie musimy tworzyć własnych aplikacji raportujących. SQL Server oferuje gotowe rozwiązanie w oparciu o środowisko .NET.

Usługi integracji danych (Integration Services)

SSIS – SQL Server Integration Services – jest to dedykowane środowisko dla procesów ETL (Extract Transform and Load). Integracji i przetwarzania danych z różnych źródeł. Dla przykładu firma analityczna z branży farmaceutycznej, otrzymuje co miesiąc dane o sprzedaży leków od różnych producentów w formie plików XML. Są one umieszczane na serwerze plików i przetwarzane przez automatyczne procesy SSIS zasilając bazę danych z plików dostarczanych przez dostawców.


Najważniejsze narzędzia pakietu MS SQL Server

W zależności od edycji, mamy możliwość wyboru w trakcie instalacji spośród dostępnych funkcjonalności i narzędzi. Poniżej ogólny opis najważniejszych z nich.

SQL Server Management Studio (SSMS)

Graficzny interfejs użytkownika (GUI), przeznaczony do administrowania, tworzenia baz, obiektów bazodanowychoraz do pisania i testowania skryptów, zapytań. Jest wygodnym narzędziem dla deweloperów – daje np. możliwość podglądu planów wykonania. Posiada szereg wygodnych funkcjonalności np. mechanizm IntelliSens znany z VS (podpowiadanie nazw obiektów, słów kluczowych). Za pomocą SSMS mamy dostęp do wszystkich obiektów bazodanowych. Możemy tworzyć kompletne rozwiązania, administrować serwerem. Tworzyć projekty, generować skrypty etc. Istnieje na rynku szereg alternatywnych rozwiązań. Spośród nich, godnymi uwagi są z pewnością produkty firmy RedGate oraz TOAD.

SQL Server Configuration Manager

Aplikacja do konfiguracji usług, protokołów komunikacyjnych, aliasów. Podstawowe narzędzie związane z konfiguracją i dostępem (protokoły) usług serwera.

SQL Server Profiler

Aplikacja do śledzenia przetwarzanych poleceń w silniku bazodanowym. Niezastąpione przy szukaniu wąskich gardeł, zbierania danych do optymalizacji systemu. Możemy dzięki niemu przechwycić praktycznie wszystkie procesy, wykonywane przez SQL Server.

Zapytania, procedury składowane, wywoływania triggerów, logowania, transakcje i inne procedowane zdarzenia. SQL Server Profiler umożliwia zapis śladu i jego późniejszą analizę np. w Database Engine Tunning Advisor celem optymalizacji struktur (dodanie indeksów, statystyk etc.)

Database Engine Tunning Advisor (DETA)

Aplikacja do analizy i optymalizacji zapytań – wspiera procesy tworzenie indeksów, widoków indeksowanych, statystyk i partycji. Jako źródło przyjmuje np. zbiór informacji śladu – trace – przechwycony przez Profiler lub konkretny skrypt zapytania.

Business Intelligence Development Studio

IDE (Integrated Development Environment) dedykowane środowisko oparte o .NET framework, do tworzenia raportów w ramach Reporting Services, paczek SSIS (Integration services) oraz usług analitycznych (Analysis Services).

SQLCMD

Prosta aplikacja, za pomocą której mamy możliwość połączenia się z bazą danych z poziomu linii poleceń. Idealnie nadaje się do wszelkich czynności administracyjnych, skryptów. Szczególnie przydatna do automatyzacji zadań w SQL Server Express, w której nie mamy dostępnej usługi SQL Server Agent.


* Projekt Hekaton, dotyczy funkcjonalności przetwarzania transakcyjnego in-memory

Środowisko testowe

Nauka jakiegokolwiek języka „na sucho”, mija się z celem. Dotyczy to zarówno tradycyjnych języków obcych ale także programowania czy języka SQL. Wszystkie tematy poruszane w tym kursie, najlepiej przećwiczyć na własnym poligonie. W trakcie pisania, pojawiają się nowe pytania, można szerzej przećwiczyć różne warianty i tym samym lepiej zrozumieć temat.

Do pełnego zrozumienia zagadnień poruszanych tutaj, koniecznie powinieneś zbudować sobie środowisko testowe.

Jeśli chodzi o SQL Server sugeruję zacząć od wersji najnowszej (obecnie 2017).

Serwer testowy

Do celów edukacyjnych, idealne są edycje darmowa Express oraz testowa Evaluation Edition (180-dniowy trail w najwyższej wersji Enterprise). Zagadnienia przedstawione w tym kursie, możesz w pełni przetestować na darmowej wersji Express dostępnej tutaj.

Co prawda jej możliwości są okrojone w stosunku do pełnych, płatnych wersji (pod względem wydajnościowym, funkcji związanych z wysoką dostępnością, BI etc.), ale jeśli chodzi o naukę SQL to w zupełności wystarczy.

Wersja SQL Server Express to platforma, którą możesz używać również we wdrożeniach komercyjnych. Jednymi z bardziej dotkliwych ograniczeń są :

  • maksymalny rozmiar bazy do 10GB
  • procesy SQL Servera będą wykorzystywały max jeden procesor (lub 4 rdzenie) oraz 1 GB RAM.

Pełne porównanie funkcjonalności różnych wersji SQL Server 2012 – znajdziesz na oficjalnych stronach Microsoft.

Instalując serwer, pamiętaj o zaznaczeniu narzędzi do zarządzania bazami danych czyli Microsoft SQL Server Management Studio. Jest to graficzny interfejs użytkownika, dzięki któremu w prosty sposób możesz zarządzać serwerem, bazami i wszystkimi obiektami. Jest to też wygodne środowisko deweloperskie, do pisania, testowania zapytań i skryptów.


Testowe bazy danych

Przykłady prezentowe w tym kursie, bazują na dwóch oficjalnych, testowych bazach danych. Możesz je pobrać tutaj.

  • Northwind – prosta, mała baza, znana bardzo dobrze ze starszych wersji SQL Server. Używam jej bo zawiera proste struktury tabel, na których można prezentować bardziej złożone zapytania, bez „zaciemniania” sedna tego co chce pokazać. Do instalacji, wystarczy uruchomić skrypt SQL (otwórz go i uruchom w Microsoft SQL Server Management Studio) – do pobrania tutaj.
  • AdventureWorks2008 – znacznie bardziej zaawansowana, posiada wiele cech rzeczywistej, produkcyjnej bazy danych. Tu z uwagi na liczbę, różnorodność danych, łatwiej zaprezentować aspekty związane z wydajnością zapytań. Najłatwiej „zainstalować” ją poprzez dołączenie do bazy – prawy strzał w oknie Object Explorera na Databases i Attach. Wystarczy następnie wskazać plik bazy z rozszerzeniem mdf (podstawowy plik bazy danych). Baza dostępna w różnych wersjach (OLTP,DW). W kursie korzystam z AdventureWorks2008, do pobrania na stronach CodePlex, gdzie znajdziesz również jej pozostałe wersje.
    Env_att
  • Twoje własne testowe bazy danych. Nic nie stoi na przeszkodzie, żebyś tworzył własne testowe bazy danych. Oczywiście musisz mieć uprawnienia na serwerze do ich tworzenia, ale zakładając że jesteś sam sobie sterem, żaglem i adminem, możesz to wykonać za pomocą T-SQL :
    CREATE DATABASE Testowa
    

Środowisko testowe i produkcyjne

Z definicji, środowiska testowe i produkcyjne powinny być maksymalnie odseparowane, najlepiej hardware’owo.

Jeśli chcesz testować zapytania na bazach produkcyjnych, powinieneś zawsze uwzględnić fakt, że działanie ich wpływa na pracę serwera. Odczytujesz przecież konkretne dane, zatem korzystasz z zasobów dyskowych, pamięci i mocy procesora maszyny. Niektóre z nich mogą znacząco wpłynąć na ogólną wydajność (np. jeśli przez przypadek napiszesz zapytanie będące iloczynem kartezjańskim, lub gdy będziesz chciał odczytać wszystkie rekordy tabeli, która zawiera wiele milionów rekordów).

Jako administrator baz danych sugeruje, że jeśli musisz testowo odpytywać bazy produkcyjne lub ćwiczyć na nich swoje umiejętności, zastosuj się do kilku poniższych zasad :

  • jeśli możesz, ćwicz zawsze na bazie testowej na serwerze testowym :) (może to być kopia zapasowa bazy produkcyjnej)
  • ustaw poziom izolacji swojej sesji na Read Uncommitted. Przyspieszy to czas odczytów (nie będziesz czekał na zwolnienie blokad) Twoich zapytań i Twojej działalności na danych produkcyjnych. Wykonasz to za pomocą polecenia SET. Jeśli testujesz swoje zapytania, zazwyczaj izolacja między transakcjami nie jest istotna (chyba że testujesz współbieżność).
    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
    
  • próbkuj wyciągane dane z tabel stosując klauzulę TOP (jeśli chcesz na przykład sprawdzić co dana tabela zawiera). Nie pobieraj wszystkiego jak leci – select * from tabela to bardzo złe zapytanie w środowisku produkcyjnym

Obiekty w bazach danych

Artykuł ten opisuje przegląd najważniejszych obiektów dostępnych w SQL Server. Ma na celu pokazać ich różnorodność, wyjaśnić ich ogólne przeznaczenie. Chcę tutaj głównie zaznajomić początkujących użytkowników baz danych ze środowiskiem i obiektami, które można spotkać lub które mogą się przydać w kontekście pisania zapytań.

Serwer czyli System Zarządzania Bazą Danych (SZBD)

Od tego trzeba zacząć. System zarządzania bazami danych (Relational DataBase Management System RDBMS) – to kompletne środowisko w którym tworzymy, zarządzamy i pracujemy na bazach. Najpopularniejszymi są MS SQL Server, Oracle, MySQL, DB2, PostrgeSQL.

Wszystkie obiekty na serwerze tworzą strukturę hierarchiczną – serwer (instancja) jest na czele tej hierarchii.

Zawiera w sobie wszystkie komponenty odpowiedzialne za pracę systemu bazodanowego. Realizuje procesowanie zapytań, zarządzanie składowaniem danych, dostępem itd. . Jest to podobnie jak system operacyjny (tyle że warstwę wyżej w modelu ISO), całe środowisko w którym poruszamy się mówiąc o pracy z bazami danych.

Na danej fizycznej maszynie, możemy mieć zainstalowanych wiele różnych serwerów bazodanowych (np. kilka instancji MS SQL Server). Mówiąc o RDBMS SQL Server – jest to usługa systemowa, czyli aplikacja działająca w tle, realizująca wszystkie zadania związane z obsługą baz danych.

Wszystkie obiekty opisane poniżej, są tworzone i zarządzane właśnie na danym serwerze bazodanowym.


Baza danych

Na każdym serwerze, możemy utworzyć wiele baz danych. W implementacji SQL Server, spotkamy się z bazami systemowymi (master, model, msdb, tempdb) oraz nazwijmy je „regularnymi”, użytkownika – czyli np. bazy sklepu internetowego, firmy produkcyjnej etc..

Hierarchię obiektów dobrze obrazuje drzewo widoczne w oknie Object Explorera w Microsoft SQL Server Management Studio.
DbObjects_01

Każda baza, wraz ze wszystkimi danymi, które zawiera, jest składowana niezależnie, w przynajmniej dwóch plikach (pliku bazy i pliku logu transakcyjnego).

Wszystkie obiekty bazodanowe, muszą posiadać unikalną nazwę, w ramach bazy danych. W pełni kwalifikowana nazwa każdego obiektu jest czteroczłonowa, zgodna ze schematem :

<nazwa_serwera>.<nazwa_bazy_danych>.<nazwa_schematu>.<nazwa_obiektu>

Dzięki temu, jest ona jednoznacznie określona. W skryptach, zapytaniach SQL, możemy odwoływać się do obiektów w różnych bazach i na różnych serwerach – stąd w zależności od potrzeb stosujemy krótszą lub dłuższą formę.

Minimalną zalecaną nazwą po której odwołujemy się do określonego obiektu, jest nazwa dwuczłonowa – czyli <nazwa_schematu>.<nazwa_obiektu>.

Schemat

Ponieważ wszystkie obiekty tworzone są w ramach jakiegoś schematu – ważne abyś dowiedział się o nich na początku. Schemat to niezależna warstwa, związana z zarządzaniem bezpieczeństwem. Jest to kontener, w ramach którego tworzone są obiekty. Dzięki temu, nadając uprawnienia do danego schematu, możemy kontrolować uprawnienia na poziomie wszystkich obiektów należących do niego. Każdy użytkownik posiada schemat domyślny, który jest rozpatrywany wtedy, gdy odwołujemy się do obiektu tylko po jego nazwie.

Żeby sprawdzić jaki jest domyślny schemat w ramach bazy, można użyć do tego, prostej funkcji systemowej :

select SCHEMA_NAME() as DefaultSchema;

Mój schemat domyślny to dbo.Następujące zapytanie, zwróci komunikat o błędzie :

use AdventureWorks2008
go
 
select FirstName,LastName from Person
Msg 208, Level 16, State 1, Line 2
Invalid object name 'Person'.

Stanie się tak, ponieważ nie użyłem w zapytaniu nazwy schematu w którym zawarta jest tabela Person. Został więc określony mój schemat domyślny czyli dbo. W tym zapytaniu odniosłem się do tabeli dbo.Person, której nie ma w bazie AdventureWorks2008.

Jest to bardzo ważna zasada, aby pamiętać o tym, że odwołujemy się zawsze do nazwy obiektu razem z nazwą schematu w której ten obiekt się znajduje. Zapytanie więc powinno wyglądać następująco :

Select * from Person.Person

Tabela

Podstawowymi obiektami w każdej bazie są tabele. W tym miejscu zaczyna się tak naprawdę modelowanie rzeczywistości na postać relacyjną. Tabela – to definicja pewnej klasy obiektów które chcemy przechowywać. Każda tabela zawiera zbiór elementów opisany za pomocą atrybutów (kolumn). Każdy atrybut (kolumna), jest określany typem danych (np. data urodzin powinna być opisana jako typ danych daty, a liczba. Widzimy więc jak mocno hierarchizowana jest ta struktura.
DbObjects_05
Tabela to obiekt nadrzędny w stosunku do :

  • kolumn czyli atrybutów, opisujących elementy przechowywane w tabeli,
  • kluczy – czyli relacji do innych tabel,
  • ograniczeń (constraints) służących do zapewnienia integralności danych,
  • procedur wyzwalanych (triggers) – obiektów programistycznych, za pomocą których możemy realizować rozmaite cele, np. archiwizowanie modyfikowanych elementów.
  • indeksów i statystyk – obiekty poprawiające wydajność zapytań.

W zapytaniach odwołujemy się tylko do nazw tabel, kolumn. Potrzebna jest także wiedza na temat kluczy w kontekście pisania kwerend do wielu tabel (po jakich kolumnach będziemy łączyć ze sobą tabele). Pozostałe obiekty dotyczą projektu samej tabeli, zapewnienia integralności danych (typy danych użyte w kolumnach, ograniczenia i procedury wyzwalane) i służą do optymalizacji zapytań (statystyki i indeksy).
Nie będę ich tu szczegółowo opisywał bo wykraczają poza zakres tego kursu. Nie są bezpośrednio związane z DQL czyli pisaniem zapytań.

Widok

Widok inaczej perspektywa (określenie używane w ORACLE), to po prostu zapisana kwerenda, czyli inne spojrzenie (stąd pewnie nazwa widok) na tabele. Są one nazywane czasem wirtualnymi tabelami – bo przecież zapytanie zwraca nam taką „wirtualną tabelę”. Rezultatem jest przecież zawsze pewien zbiór elementów. Są wygodnym sposobem, na ukrywanie potencjalnie skomplikowanej struktury bazy przed użytkownikami (dla wygody jak również dla bezpieczeństwa). Odwołujemy się do nich w zapytaniach jak do zwykłej tabeli.
DbObjects_06

Widoki, to niezmaterializowane tabele wirtualne. W ogólności nie poprawiają wydajności zapytań, chyba że utworzymy na nich indeksy.

Synonim

To aliasy nazw obiektów. Pozwalają nadać istniejącym obiektom bardziej ludzkie imię :) lub po prostu uniezależnić aplikacje od zmian w strukturze bazy. Szczególnie pomocne przy migracjach lub modyfikacjach środowiska. Są alternatywnymi nazwami obiektów takich jak tabele, widoki, funkcje, procedury składowane.

Obiekty programistyczne

W ramach bazy, możemy tworzyć różne obiekty programistyczne. Ich przeznaczenie jest bardzo szerokie. Ograniczę się tylko do bardzo ogólnego ich opisu bo nie stanowią tematu tego kursu.
DbObjects_07

Stored Procedures

Procedury składowane to niezależne jednostki, skrypty T-SQL, realizujące dowolne funkcje programistyczne. Mogą np. importować dane z pliku, dokonując przy okazji szeregu weryfikacji (czyszczenia), wykonywać określone czynności administracyjne, utrzymaniowe. Procedury mogą przyjmować parametry i zwracać zbiory wynikowe. Dzięki nim (podobnie jak funkcją), możemy zaszyć logikę biznesową na serwerze SQL tworząc wielowarstwową strukturę aplikacji.
Procedury składowane nie mogą być używane w kwerendach, choć za ich pomocą można także realizować dostęp do danych (mogą zwracać wynik kwerendy, zapisanej w ich ciele).

Assemblies

SQL Server umożliwia integrację środowiska CLR. Możemy tworzyć obiekty programistyczne w .NET i używać ich w ramach serwera bazy danych. Jest to znakomite uzupełnienie możliwości języka SQL (który jest zoptymalizowany do działania na zbiorach) językami obiektowymi.

Database Triggers

Jest to specjalny typ procedur wyzwalanych, które mogą być wywoływane na wskutek operacji DDL czyli związane z dowolną modyfikacją obiektów bazodanowych (tworzący. Możemy za ich pomocą np. logować czy też kontrolować wszelkie zmiany w strukturze.

Funkcje

SQL Server oferuje szereg dostępnych wbudowanych funkcji systemowych. Funkcje w ogólności szeregujemy ze względu na wynik jaki zwracają na skalarne lub tabelaryczne.

Funkcje skalarne, zwracają w wyniku jednoelementowy zbiór opisany jednym atrybutem np. funkcja getdate(), która zwraca aktualną datę i czas systemowy. Stosować możemy je np. w klauzuli SELECT czy w warunku filtracji WHERE. Wszędzie tam, gdzie wartością oczekiwaną jest wartość skalarna.

Funkcje tabelaryczne mogą zwracać zbiór wieloelementowy. Stosować możemy je np. we FROM, ale już nie w SELECT. Dobry przykładem jest funkcja OPENQUERY, za pomocą której możemy np. dobrać się w kwerendzie do zawartości danych w pliku excel.
Oprócz funkcji wbudowanych, systemowych, mamy możliwość tworzenia własnych metod. Są trzy rodzaje funkcji użytkownika – skalarne, tabelaryczne proste i tabelaryczne złożone. Dzięki nim zrealizujemy dowolne cele programistyczne. W dalszej części tego kursu opisuję w detalach zastosowanie

Types

Typy danych użytkownika – to typy pochodne z już istniejących. Jeśli np. stosujemy w bazie typ danych char(12) i używamy go w różnych tabelach wiele razy – możemy go zdefiniować jako typ użytkownika globalny i wszędzie tam gdzie będzie potrzebny po prostu używać po nazwie własnej.

Rules

Ten typ obiektu będzie wycofane w przyszłych wersjach SQL Server.
Idea reguł jest bardzo podobna do typów użytkownika. Są to definicje ograniczeń (constraintów), które możemy podpiąć do różnych kolumn, tabel.

Defaults

Ten typ obiektu będzie wycofane w przyszłych wersjach SQL Server.
Wartości domyślne – to trzeci typ obiektów wielokrotnego użytku do określania struktury i własności kolumn po regułach i typach użytkownika. Jest on niezależnym obiektem, który może być „podpięty” pod dowolne kolumny tabel jako definicja ich wartości domyślnej. Zgodnie z nią, będą uzupełniane kolumny w momencie dodawania wierszy jeśli w danym elemencie nie będzie jawnie określona wartość.

Sequences

Sekwencje to nowy typ obiektów w SQL Server 2012. Są to liczniki, generatory kolejnych liczb, nadające numery według określonego porządku, które nie są zależne od konkretnej tabeli.


Pozostałe obiekty

Przedstawione powyżej obiekty są tylko podzbiorem z dostępnych struktur, które oferuje SQL Server. Istnieje szereg obiektów związanych z bezpieczeństwem, usługami Brokera (kolejki, wiadomości etc.) czy indeksami pełnotekstowymi.