Sanity Checks w zapytaniach

Sanity checks w zapytaniach to proste sprawdzenia poprawności wyniku przed jego dalszym wykorzystaniem.

Na czym polegają sanity checks w zapytaniach

Sanity checks w zapytaniach to proste sprawdzenia, które mają potwierdzić, że otrzymany wynik jest logiczny, kompletny i zgodny z założeniami przed wykorzystaniem go w dalszej części programu, raportu albo procesu diagnostycznego. Nie zastępują pełnych testów jednostkowych, integracyjnych ani kontroli jakości danych. Ich zadaniem jest szybkie wykrycie oczywistych nieprawidłowości, takich jak pusty wynik tam, gdzie rekordy powinny istnieć, ujemna liczba elementów, powtórzone identyfikatory albo wartość rażąco odbiegająca od oczekiwanego zakresu.

Kontrola może dotyczyć zarówno samego zapytania, jak i danych zwróconych przez zapytanie. Sprawdza się między innymi liczbę wierszy, obecność wymaganych kolumn, typy wartości, wartości puste, unikalność kluczy oraz zgodność relacji między polami. Przykładowo zapytanie wyszukujące aktywne zgłoszenia serwisowe może zostać uznane za podejrzane, jeżeli zwróci rekord z datą zamknięcia wcześniejszą niż data utworzenia albo zgłoszenie bez identyfikatora urządzenia.

Zakres kontroli wyniku przed dalszym użyciem

Jednym z podstawowych sanity checks jest sprawdzenie, czy wynik nie jest pusty i czy jego liczność mieści się w przewidywanym zakresie. Pusty rezultat może oznaczać brak danych, ale może również wynikać z błędnego warunku filtrowania, pomyłki w nazwie kolumny, niewłaściwego zakresu dat albo połączenia tabel po nieodpowiednim kluczu. Z kolei niespodziewanie duża liczba wierszy może wskazywać na brak warunku ograniczającego, niezamierzone powielenie rekordów przez relację jeden-do-wielu albo pominięcie klauzuli eliminującej duplikaty.

Warto także kontrolować wartości graniczne i zależności logiczne. Licznik rekordów nie powinien być ujemny, procent powinien mieścić się w zakresie od 0 do 100, a kwota nie powinna zmieniać znaku bez wyraźnej reguły biznesowej. Jeżeli zapytanie zwraca sumę, średnią lub minimum, można porównać wynik z prostym ograniczeniem wynikającym z danych wejściowych. Średnia nie może być mniejsza od najmniejszej wartości ani większa od największej wartości w tym samym zbiorze. Przy danych czasowych należy sprawdzić kolejność dat, a przy danych identyfikacyjnych — format, niepustość i oczekiwaną unikalność.

Sanity check może obejmować również kontrolę spójności między kilkoma wynikami. Suma elementów w podziale na kategorie powinna odpowiadać liczbie wszystkich elementów, chyba że filtr jawnie wyłącza część rekordów. Liczba urządzeń oznaczonych jako sprawne nie powinna przekraczać liczby urządzeń ogółem. Takie porównania pomagają wykryć błędy w filtrach, agregacji, grupowaniu oraz łączeniu danych, zanim niepoprawny rezultat zostanie zapisany, wyświetlony albo przekazany do kolejnego zapytania.

Sanity checks a błędy konstrukcji zapytania

Nieprawidłowy wynik może być skutkiem błędu składniowego, ale częściej wynika z poprawnego technicznie zapytania, które nie realizuje zamierzonej logiki. Dlatego sanity check powinien odpowiadać na pytanie, czy zapytanie zwraca właściwy zbiór danych, a nie tylko czy silnik je wykonał. Szczególnej uwagi wymagają warunki łączące operatorów AND i OR, filtry dotyczące wartości pustych, przedziały dat oraz połączenia tabel. Brak nawiasów w złożonym warunku może zmienić kolejność interpretacji wyrażeń i rozszerzyć wynik o rekordy, które nie powinny zostać uwzględnione.

Przy łączeniu tabel kontroluje się, czy liczba wynikowych wierszy nie wzrosła wskutek powielenia danych. Jeżeli tabela urządzeń zawiera jeden rekord na komputer, a tabela historii wiele wpisów dla tego samego komputera, zwykłe połączenie może zwrócić wiele wierszy dla jednego urządzenia. Nie musi to oznaczać błędu, ale rezultat powinien odpowiadać celowi zapytania. Gdy potrzebna jest lista urządzeń, należy zweryfikować, czy wynik nie wymaga agregacji, wyboru ostatniego wpisu lub usunięcia powtórzeń. W przypadku agregacji sprawdza się także, czy kolumny nieobjęte funkcją agregującą są prawidłowo użyte w grupowaniu.

Kontrole można wykonywać ręcznie dla pojedynczego zapytania albo zapisać w kodzie jako warunki walidacyjne. Program może przerwać dalsze przetwarzanie, zwrócić komunikat diagnostyczny lub oznaczyć rezultat do dodatkowej weryfikacji, gdy liczba rekordów przekroczy ustalony próg albo pojawi się wartość spoza zakresu. Ważne jest rozróżnienie błędu od sytuacji dopuszczalnej. Brak wyników może być prawidłowy dla wyszukiwania bez dopasowań, lecz powinien zostać potraktowany jako problem, jeśli zapytanie pobiera obowiązkową konfigurację albo dane potrzebne do uruchomienia programu.

Wykorzystanie kontroli wyników w serwisie komputerowym

W aplikacjach używanych na laptopach i komputerach PC sanity checks pomagają ograniczyć skutki błędnych odczytów konfiguracji, historii usterek, list plików, parametrów sprzętu oraz wyników testów. Kontrola nie naprawia sama w sobie uszkodzonego dysku, pamięci operacyjnej ani systemu, ale może wskazać, że narzędzie diagnostyczne zwróciło niepełne lub niespójne dane. Przykładowo wynik bez identyfikatora urządzenia, z nierealną temperaturą albo z nagle zmniejszoną liczbą wykrytych podzespołów powinien zostać sprawdzony ponownie przed sformułowaniem diagnozy.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a podczas prac diagnostycznych poprawność wyników zapytań może być jednym z elementów oceny działania systemu, aplikacji lub narzędzia serwisowego. Przydatne jest porównanie rezultatu z informacjami widocznymi w systemie, dokumentacją urządzenia oraz wynikami powtórzonego odczytu. Jeżeli dane nie są spójne, należy najpierw ustalić, czy przyczyną jest błąd zapytania, nieaktualna konfiguracja, problem z komunikacją z urządzeniem czy rzeczywista usterka badanego komputera.

Dobrze zaprojektowany sanity check powinien być krótki, jednoznaczny i powiązany z konkretnym założeniem technicznym. Nadmiar przypadkowych kontroli może utrudnić analizę i generować fałszywe alarmy. Najbardziej użyteczne są te, które sprawdzają warunki krytyczne: istnienie wyniku, poprawność kluczy, zgodność typów, zakres wartości, brak nieuzasadnionych duplikatów oraz zachowanie oczekiwanej liczności danych. Dzięki temu błędny rezultat zostaje zauważony na etapie odczytu, a nie dopiero wtedy, gdy doprowadzi do niewłaściwej konfiguracji, niepełnego raportu lub błędnej decyzji serwisowej.