Prezentacja z 28. spotkania WiT we Wrocławiu Autor: Roman Czarko-Wasiutycz

1. Roman Czarko-Wasiutycz
Roman.Czarko@gmail.com

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 :)
2

3.  Projektowanie
 Normalizacja
 Klucze, Indeksy
 Typy danych
 Triggery, kursory
 Dokumentacja
 Warstwy
3

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?
4

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
5

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
6

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
7

8.  Klucze – po co używać?
◦ primary / foreign
 Identyfikacja rekordów
 Integralność danych
 Czytelność
 Łatwiejsze utrzymanie
 Prostsze raportowanie
 Wsparcie narzędzi
8

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
9

10. 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
11

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
12

13.  Zabezpieczenia (?)
 Logiczne rozdzielenie funkcjonalności
 Odwoływanie się do obiektów [sch].[tbl]
15

14.  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
16

15.  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
17

16.  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.
18

17.  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
19

18.  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!
20

19. Ślepe wdrażanie „najlepszych praktyk”
jest najlepszym przykładem
najgorszych praktyk
22

20. Polish SQL Server User Group
 http://plssug.org.pl
 http://meetup.com/PLSSUG
 http://youtube.com/PLSSUG
23

21. 24
Jeśli masz pytanie to jest dobry czas, żeby je zadać 