Embed Size (px)
Citation preview
2
Od ponad 10 lat zbieram doświadczenia związane z technologiami Microsoftu. Poczynając od developera PHP i C#, administratora SharePoint poprzez administrację bazami Microsoft SQL Server na projektowaniu i rozwijaniu hurtowni danych kończąc.
Posiadacz tytułów: MCTS, MCSA: SQL Server 2012, MCSE: Business Intelligence.
Przez trzy lata Członek zarządu Stowarzyszenia Użytkowników SQL Server PLSSUG
Lider Wrocławskiego oddziału Stowarzyszenia PLSSUG.
Wolnotariusz oraz współorganizator konferencji SQLDay.
Prywatnie fan gier komputerowych :)
O Mnie
3
Projektowanie Normalizacja Klucze, Indeksy Typy danych Triggery, kursory Dokumentacja Warstwy
Agenda
4
Dane czy informacje? Czy tylko ja będę tą bazę/tabelę
używał/rozwijał? Sztuka dla sztuki czy dobre rozwiązania? Łatwiej jest „zrobić taska” na „odwal się” :/ Po co „marnuję” czas na projektowanie?
Po co projektować?
5
Każdy fakt przechowywany w bazie danych powinien być wyrażalny w niej tylko na jeden sposób
Tabela powinna mieć identyfikator Tabela powinna zawierać dane z jednej
domeny logicznej Tabela nie powinna zawierać kolumn w
których dane się powtarzają Kolumna powinna zawierać dane
niepodzielne
Normalizacja
6
Mniejsza zajętość miejsca Szybsze sortowanie i tworzenie indeksów Większa ilość indeksów klastrowych Węższe i mniejsze indeksy Mniej indeksów per tabela. Większa wydajność operacji CRUD Łatwiejsze utrzymanie
Normalizacja - zalety
7
Zbyt mała normalizacja będzie powodowała nadmierne powtarzanie danych
Zbyt duża normalizacja prowadzi do nadmiernej ilości tabel i złączeń
Oba spowodują pogorszenie wydajności i zwiększone koszty utrzymania
Normalizacja
8
Klucze – po co używać? ◦ primary / foreign
Identyfikacja rekordów Integralność danych Czytelność Łatwiejsze utrzymanie Prostsze raportowanie Wsparcie narzędzi
Klucze
9
Jak działają indeksy Gdzie w indeksie są dane? Z czym wiąże się zbyt duża liczba indeksów Indeksy w OLTP i DWH Jak typować kolumny do indeksowania
Indeksy
10
CREATE NONCLUSTERED INDEX [IX_accountNumber_bankName] ON [dbo].[Account]( [accountNumber] ASC, [bankName] ASC ) INCLUDE ( [bankNumber]);
CREATE CLUSTERED INDEX [CX_Id] ON [dbo].[Acount] ([Id] ASC)
8K
8K 8K 8K
8K 8K8K 8K 8K
DANE W CI
CI / NCI
11
Pomyśl jak będzie wyglądał dostęp do danych a jak wstawianie nowych wierszy? Używane w klauzulach WHERE, JOIN, ORDER
BY, GROUP BY – zwróć uwagę na SELECT Dane unikalne lub z dużą różnorodnością Dane w kolumnie są sekwencyjne
(Clustered!) Stałe, niezmienne dane w kolumnie Małe typy danych Ilość indeksów dostosuj do charakteru tabeli
Indeksy – jak typować kolumny
12
Przechowywanie danych (dysk, pamięć, indeksy – strony)
Typy tekstowe [n][var]char(x) GUID XML, [var]binary(x), filestream, file tables Własne, nazwane typy danych
Typy danych
15
Zabezpieczenia (?) Logiczne rozdzielenie funkcjonalności Odwoływanie się do obiektów [sch].[tbl]
Schematy
16
Po co używać? tylko w specyficznych przypadkach?
Logika w bazie :/ Co zamiast?
◦ constraints◦ defaults◦ computed columns / indexed cc◦ Change Data Capture / Change Tracking◦ procedury do wstawiania danych
Triggery dla DDL
Triggery to… zło?
17
Wyznaczanie wartości w kolumnie ◦ lepiej: computed column, procedure
Złożone więzy integralności ◦ lepiej: uprościć model, procedury, constrainty
Złożone zasady biznesowe ◦ lepiej: logika w warstwie dostępowej a nie w
bazie! Audyt modyfikacji danych
◦ lepiej: CDC/ CT – mniej obciążające (CDC w wersji Enterprise), kolumna z datą wstawienia + default
Zło… znaczy Triggery
18
To zależy ;) Bazy relacyjne oparte o teorię zbiorów Kursory nie powinny być używane
zamiast operacji relacyjnych Mogą być użyteczne gdy kursor iteruje
zbiory a nie wiersze – ale to już powinna być kwestia optymalizacji
Kursory nie są złem. Złem jest ich błędne użycie.
Kursory to… jeszcze większe zło?
19
Opisowe nazwy Opisy (EXEC sys.sp_addextendedproperty)
dokumentacja razem z kodem na etapie tworzenia gdy programista jeszcze wie czego dotyczą dane
Dodanie opisu zajmuje mało czasu a zaoszczędza bardzo dużo przy późniejszym utrzymaniu bazy
Opisy – warto używać!
20
Widoki, procedury, funkcje jako podział na warstwy w samej bazie danych
Znacznie uproszczona optymalizacja Prostszy refaktoring bazy Enkapsulacja Bezpieczeństwo Testowalność W aplikacji warstwowe podejście się
sprawdza – to samo sprawdza się w bazie danych!
Warstwy – jak cebula
22
Ślepe wdrażanie „najlepszych praktyk” jest najlepszym przykładem
najgorszych praktyk
23
Polish SQL Server User Group
http://plssug.org.pl http://meetup.com/PLSSUG http://youtube.com/PLSSUG
PLSSUG
24
Jeśli masz pytanie to jest dobry czas, żeby je zadać
Dziękuję za uwagę
