.

1. SQL ≠
SQL żyje i ma się dobrze
Bardzo krótki przewodnik po wbeosrst tp praracctitsiseess w w M MSS S SQQLL

2. 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.

3. 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 WHERE
DataUtworzenia >= `2014-09-01T00:00:00’ AND DataUtworzenia < `2014-09-01T00:00:00’
YEAR(DataUtworzenia) = 2014 AND MONTH(DataUtworzenia) = 9

4. JOIN ≠ .Join()
JOIN to nie .Join(…).
No, nie tylko.
• Poznaj różnice między rodzajami złączeń.
• Korzystaj ze złączeń w zapytaniach
SELECT A.A.Id
Id
FROM A
LEFT JOIN B ON A.Id = B.Id
WHERE B.Id IS NOT NULL
poprawnie i świadomie.
FROM A
INNER JOIN B ON A.Id = B.Id
• Nie zapominaj o CROSS JOIN.
• Nie zawsze JOIN jest wydajniejszy od podzapytania!

5. INT ≠ VARCHAR
Typy 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

6. 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?

7. deNF ≠
Denormalizacja to nie zuoooo
…w niektórych przypadkach.
• 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.

8. 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.

9. Procedura ≠ SELECT
Procedura to nie to samo co zwykły SELECT
(chociaż może nim być).
• 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
, zwłaszcza jeżeli są wymówką dla braku znajomości SQL.

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

11. Inne, też ważne
W 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!

12. 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?