Czesto w sieci widzę pytania typu: jak dobrze pisać zapytania SQL? albo jakie są dobre praktyki pisania zapytań sql? itp. Postanowiłem podzielić się z Wami kilkoma poradami tego typu. Modyfikacja "swojego warsztatu" zalezy oczywiście od stopnia Twojego zaawandowania w pisaniu zapytań ale może komus się przydadzą. Podane poniżej porady stosuję osobiście i wynikaja one z mojego długoletniego doświadczenia w pracy z bazami danych.
1. Nie rzucaj sie od razu na głęboką wodę.
Jeśli masz do napisania jakieś skomplikowane zapytanie to dobrym sposobem jest rozbić je sobie na kilka kroków. Nie zaczynaj od razu pisać postaci finalnej tylko dojdź do tej postaci etapami. Chodzi o to, że jak zbudujesz dość duże zapytanie to ciężko jest później szukać ewentualnych błędów a tak jak podzielisz prace na mniejsze etapy to za każdym razem przy końcu danego etapu możesz sprawdzić poprawność swojego zapytania.
2. Podzapytania testuj osobno.
Często się zdarza, że w swoim zapytaniu potrzebujesz utworzyć podzapyanie. Ja podzapytania staram się budować obok głównego zapytania i dopiero jak sie upewnię, że działa ono poprawnie dołączam je do zapytania głównego. Czasami zdarza się, że Twoje zapytanie zwraca błędne wyniki a Ty ciągle analizujesz "główne zapytanie" a tak naprawdę to Twoje podzapytanie może zwracać błędne wyniki cząstkowe.
3. Poprawność, czytelność, optymalizacja
Bardzo często za szybko i za dużo chcesz zrobić w jednym kroku. Od razu przy budowaniu myślisz o optymalizacji i to nie jest generalnie złe. Ale często za bardzo skupiasz się na optymalizacji na samym początku i cierpi na tym poprawność i czytelność zapytania.
Moim zdaniem lepiej jest zacząć od poprawności i czytelności zapytania. Oczywiście kluczowa jest tutaj poprawność ale NIE bagatelizujcie czytelności zapytania. Czasami na szybko próbujesz coś stworzyć. Piszesz i piszesz i Twoje zapytanie staje się juz dosyć sporawe i nagle błąd. Bez zadbania od razu o czytelność zapytania trudno Ci będzie szybko zdiagnozować problem.
4. Zapoznaj się z danymi.
Jak nie poznasz dobrze zbioru danych do którego będziesz pisał zapytania to przygotuj się na drogę przez mękę. Poświęć czas na poznanie tabel, zależności pomiędzy nimi i typów danych w kolumnach itd. Ale także a może przede wszystkim zastanów się jakie wartości mogą przechowywać Twoje tabele/kolumny i głównie chodzi mi tutaj np o NULL-e. Bardzo często to właśnie wartości null mogą bardzo pomóc lub wygenerować jakiś nichciany błąd. Powiedzmy, że mamy kolumnę "DataKoniecZatrudnienia" i tam przy niektórych pracownikach są wartości NULL. Oznacza to, że jeśli jest NULL to pracownik jeszcze pracuje w firmie bo w tej klumnie nie ma konkretnej wartości i w przykładowym zapytaniu np.: pokaż mi wszystkich pracowników, którzy pracują aktualnie w firmie ta informacja może bardzo pomóc. Ale np. okazuje się, że są przypadki kiedy przy pracowniku nie ma ani daty zatrudnienia ani daty końca zatrudnienia i oznacza to, że pracownik jest zatrudniany np. na umowy zlecenia ale jest wykazywany na liście pracowników itp.
Sam widzisz, że kombinacji może być wiele i bez dobrego rozpoznania tematu można nieźle zamieszać zapytaniem.
5. Do poprawności analizuj mniejsze ilości danych lub pojedyncze małe lokalizacje/działy.
Jak napiszamy sobie zapytanie które "wypluwa" nam dziesiątki tysięcy, a może i więcej, rekordów to skąd będziesz wiedział, że zapytanie zwraca poprawne wyniki? Żeby zminimalizować ryzyko wykonuj swoje zapytania na mniejszych ilościach danych np. z jednego miesiąca lub np. z jednego działu firmy itp. Niestety mniejsza ilość danych nie gwarantuje oczywiście pełnego sukcesu bo ograniczamy także ilość możliwości wystąpienia takichś niestandardowych sytuacji. Chodzi tylko o to, że np. na mniejszej ilości danych jesteś w stanie szybciej przeanalizować poprawność wyników zapytania.
6. Robisz UPDATE? Pamiętaj o kryteriach WHERE.
Informatyk jest jak saper. Niektóre czynności robi tylko raz i z reguły to wystarczy żeby uczyć się na swoich błędach. Czasami jednak straty są już nie do naprawienia. Przykład z życia. Pewien znajomy informatyk napisał sobie UPDATE-a w celu zmiany ceny jednego produktu w sklepie internetowym. Jakieś było jego zdziwienie jak po chwili wszystkie produkty miały takią samą cenę. Jeśli modyfikujesz jeden lub tylko kilka rekordów to przyjmij zasadę UPDATE = WHERE czyli jeśli stosujesz UPDATE to musi wystąpić WHERE z warunkami opisującymi który rekord, lub grupę rekordów, zmodyfikować w innym przypadku "polecisz po całej tabeli" i będzie rozmowa dyscyplinująca z przełożonym (w najlepszym przypadku).
To na dzisiaj tyle. Myślę, że w miarę możliwości będę ten post rozbudowywał lub dorzucał jego kolejne części.
