prezentacja 20141129

SQL ≠ SQL żyje i ma się dobrze

Bardzo krótki przewodnik po best practises w MS SQLBardzo krótki przewodnik po worst practises w MS SQL

SELECT ≠ SELECT * to zwykle nie jest dobry pomysł.

• Znaj nazwy kolumn.

• Pobieraj tylko niezbędne dane.

• Pamiętaj o indeksach.

• TOP może się przydać.

• …albo SET ROWCOUNT.

WHERE ≠ WHERE nie jest ozdobą.

• Używaj warunków w celu ograniczenia ilości pobieranych danych.

• Konstruuj warunki tak aby poprawnie korzystały z indeksów.

• …lub twórz indeksy tak aby wspomagały warunki.

• Porównując daty, nie korzystaj z funkcji niedeterministycznych.

SELECT * FROM tabela WHEREYEAR(DataUtworzenia) = 2014 AND MONTH(DataUtworzenia) = 9

SELECT * FROM tabela WHEREDataUtworzenia >= `2014-09-01T00:00:00’ AND DataUtworzenia < `2014-09-01T00:00:00’

JOIN ≠ .Join()JOIN to nie .Join(…).

• Poznaj różnice między rodzajami złączeń.

• Korzystaj ze złączeń w zapytaniach

SELECT A.Id

FROM A

LEFT JOIN B ON A.Id = B.Id

WHERE B.Id IS NOT NULL

• Nie zapominaj o CROSS JOIN.

• Nie zawsze JOIN jest wydajniejszy od podzapytania!

No, nie tylko.

poprawnie i świadomie.

SELECT A.Id

FROM A

INNER JOIN B ON A.Id = B.Id

INT ≠ VARCHARTypy danych są ważne. I różne.

• Pamiętaj żeby dane przechowywać w polach o odpowiednich typach.

• Ograniczaj wielkość pól do realnych wartości.

• W zapytaniach używaj parametrów odpowiedniego typu.

SELECT * FROM A WHERE Id = '1234'

SELECT * FROM A WHERE Id = 1234

NF ≠ Normalizacja to nie wiedza akademicka.

• Przemyśl i zaplanuj struktury danych przed implementacją.

• Używaj kluczy obcych.

• Pamiętaj, że normalizacja służy „eliminacji redundancji danych przy jednoczesnym zapewnieniu ich spójności”, co niekoniecznie przekłada się na wydajność.

• …więc po co o niej wspominam?

deNF ≠ Denormalizacja to nie zuoooo

• W uzasadnionych przypadkach pozwól sobie na redundancję danych.

• …ale żeby bazę zdenormalizować, to najpierw powinna być znormalizowana!

• Denormalizacja nie może być uzasadnieniem bur bałaganu w bazie.

…w niektórych przypadkach.

Indeks ≠ Indeksy to nic strasznego.

• Nie twórz indeksów rozbudowanych ponad potrzeby.

• Pamiętaj, że klucz obcy to nie indeks.

• Naucz się korzystać z narzędzi optymalizacyjnych.

• Widoki też można indeksować

• Dowiedz się co to jest indeks kryjący.

• Nie każdy indeks ma sens.

pod pewnymi warunkami.

Procedura ≠ SELECTProcedura to nie to samo co zwykły SELECT

• Korzystaj z procedur do wieloetapowego przetwarzania dużej ilości danych.

• Pamiętaj, że nie zawsze zwykłe zapytanie jest lepsze od procedury.

• ...ale też nie zawsze procedura jest lepsza od zwykłego zapytania.

• Uważaj na „parameter sniffing”.

• …również przy zwykłych SELECTach.

• Unikaj kursorów

(chociaż może nim być).

, zwłaszcza jeżeli są wymówką dla braku znajomości SQL.

Transakcja ≠Transakcja to nie jest niepotrzebny bagaż.

• Korzystaj z transakcji.

• …tam, gdzie jest to potrzebne!

• Obejmuj transakcją tylko kluczowy fragment zapytania.

• Pamiętaj o ustawieniu odpowiedniego poziomu izolacji transakcji.

Inne, też ważneW skrócie• Pamiętaj o hintach typu LOCK.

• Znaj różnicę między tablicą tymczasową a zmienną tabelaryczną.

• …i pomiędzy tymi strukturami a CTE.

• Naucz się korzystać z MERGE

• …oraz OUTPUT

• …oraz ROW_NUMBER() OVER (ORDER BY…)

• MYŚL!

Baza ≠Baza danych to nie niewzruszona struktura.

• Weryfikuj zapytania w miarę przyrostu ilości danych.

• Optymalizuj indeksy.

• Odświeżaj statystyki.

• Och, no po prostu zadbaj trochę o bazę danych, ok?