Najlepszy sposób na testowanie zapytań SQL [zamknięty]

I najlepsze jest to, że dla większości kompozycji widoków, otrzymasz dokładnie ten sam występ z Twoich RDBMS. (Dla niektórych nie będzie; i co z tego? Przedwczesna optymalizacja jest źródłem wszelkiego zła. Kod poprawnie najpierw następnie zoptymalizuj, jeśli zajdzie taka potrzeba.)

Oto przykład użycia kilku widoków do rozłożenia skomplikowanego zapytania.

W przykładzie, ponieważ każdy widok dodaje tylko jedną transformację, każdy może być niezależnie testowany w celu znalezienia błędów, a testy są proste.

Oto tabela bazowa w przykładzie:

create table month_value( 
    eid int not null, m int, y int,  v int );

Ta tabela jest błędna, ponieważ używa dwóch kolumn, miesiąca i roku, aby reprezentować jeden punkt odniesienia, miesiąc bezwzględny. Oto nasza specyfikacja dla nowej, obliczonej kolumny:

Zrobimy to jako przekształcenie liniowe, takie, że sortuje się tak samo jak (y, m), I takie, że dla dowolnej (y,m) krotki istnieje jedna i jedyna wartość, a wszystkie wartości są następujące po sobie: {10]}

create view cm_abs_month as 
select *, y * 12 + m as am from month_value;

Teraz to, co musimy przetestować, jest nieodłączną częścią naszej specyfikacji, a mianowicie, że dla dowolnej krotki (y, m) istnieje jedna i tylko jedna (am), a że (am)S są kolejne. Napiszmy kilka testów.

Naszym testem będzie zapytanie SQL select, z następująca struktura: nazwa testu i Oświadczenie o przypadku połączone razem. Nazwa testu jest tylko dowolnym ciągiem znaków. Instrukcja case jest po prostu case when instrukcją testową then 'passed' else 'false' end.

Instrukcje testowe będą tylko selektami SQL (zapytaniami podrzędnymi), które muszą być prawdziwe, aby test przeszedł pomyślnie.

Oto nasz pierwszy test:

--a select statement that catenates the test name and the case statement
select concat( 
-- the test name
'For every (y,m) there is one and only one (am): ', 
-- the case statement
   case when 
-- one or more subqueries
-- in this case, an expected value and an actual value 
-- that must be equal for the test to pass
  ( select count(distinct y, m) from month_value) 
  --expected value,
  = ( select count(distinct am) from cm_abs_month)  
  -- actual value
  -- the then and else branches of the case statement
  then 'passed' else 'failed' end
  -- close the concat function and terminate the query 
  ); 
  -- test result.

Uruchomienie tego zapytania daje wynik: For every (y,m) there is one and only one (am): passed

Dopóki w month_value jest wystarczająca ilość danych testowych, test ten działa.

Możemy dodać test dla wystarczających danych testowych:

select concat( 'Sufficient and sufficiently varied month_value test data: ',
   case when 
      ( select count(distinct y, m) from month_value) > 10
  and ( select count(distinct y) from month_value) > 3
  and ... more tests 
  then 'passed' else 'failed' end );

Teraz przetestujmy to kolejne:

select concat( '(am)s are consecutive: ',
case when ( select count(*) from cm_abs_month a join cm_abs_month b 
on (( a.m + 1 = b.m and a.y = b.y) or (a.m = 12 and b.m = 1 and a.y + 1 = b.y) )  
where a.am + 1 <> b.am ) = 0 
then 'passed' else 'failed' end );

Teraz włóżmy nasze testy, które są tylko zapytaniami, do pliku i uruchom ten skrypt przeciwko bazie danych. W rzeczy samej, jeśli przechowujemy nasze definicje widoku w skrypcie (lub skryptach, polecam jeden plik na powiązane widoki), który ma być uruchomiony z bazą danych, możemy dodać nasze testy dla każdego widoku do skryptu tego samego, tak aby akt (ponownego) tworzenia naszego widoku również uruchamiał testy widoku. Że sposób, oboje otrzymujemy testy regresji, gdy ponownie tworzymy widoki, a gdy Tworzenie widoku działa przeciwko produkcji, widok będzie również testowany w produkcji.