UNION ALL

UNION ALL łączy wyniki dwóch zapytań bez usuwania duplikatów, działając szybciej niż UNION.

UNION ALL — czym jest i do czego służy

UNION ALL jest operatorem SQL wykorzystywanym do połączenia rezultatów co najmniej dwóch zapytań SELECT w jeden zbiór wynikowy. Każde zapytanie źródłowe jest wykonywane według własnych warunków, a następnie jego wiersze są dokładane do wierszy zwróconych przez kolejne zapytania. Istotną cechą tego rozwiązania jest zachowanie powtórzeń. Jeżeli ten sam rekord, taka sama wartość albo identyczna kombinacja kolumn pojawi się w kilku częściach zapytania, wynik końcowy może zawierać każdą z tych pozycji.

Operator przydaje się wtedy, gdy celem jest zebranie danych z kilku tabel, okresów, źródeł albo warunków bez dodatkowej operacji sprawdzającej unikalność. Przykładowo można połączyć listę zamówień z bieżącego miesiąca z listą zamówień z poprzedniego miesiąca, dane z dwóch tabel o zgodnym układzie kolumn albo rekordy pobierane według różnych kryteriów. W wyniku powstaje jedna tabela logiczna, której liczba wierszy jest zazwyczaj sumą wierszy zwróconych przez poszczególne zapytania.

Pod względem składni UNION ALL umieszcza się pomiędzy pełnymi zapytaniami SELECT. Każda część powinna zwracać taką samą liczbę kolumn, a odpowiadające sobie kolumny powinny mieć typy danych możliwe do połączenia. Nazwy kolumn wyniku są zwykle ustalane na podstawie pierwszego SELECT-a, dlatego warto nadać im czytelne aliasy już w pierwszej części konstrukcji.

UNION ALL a UNION, sortowanie i zgodność kolumn

Najważniejsza różnica między UNION ALL a UNION dotyczy obsługi powtarzających się wierszy. UNION tworzy wynik pozbawiony duplikatów, co wymaga porównania rekordów z połączonych zbiorów. UNION ALL nie wykonuje takiej deduplikacji. Z tego powodu może działać sprawniej i zużywać mniej zasobów, szczególnie gdy dane są liczne, a powtórzenia są poprawnym elementem raportu. Szybkość nie powinna jednak być jedynym kryterium wyboru. Jeżeli powtarzające się wartości oznaczają błąd biznesowy, użycie UNION ALL może ukryć problem w danych.

Przy łączeniu zapytań znaczenie ma kolejność oraz liczba zwracanych kolumn. Nie jest konieczne, aby kolumny miały takie same nazwy w obu tabelach, ale ich pozycje muszą odpowiadać sobie logicznie. Jeżeli pierwszy SELECT zwraca identyfikator, nazwę i datę, drugi również powinien zwracać trzy wartości w tej samej kolejności. Niewłaściwe zestawienie może prowadzić do błędu składni, niepożądanej konwersji typów albo wyniku trudnego do interpretacji.

ORDER BY stosuje się zazwyczaj dopiero na końcu całej konstrukcji, aby uporządkować kompletny rezultat. Sortowanie wewnątrz pojedynczych zapytań często nie ma znaczenia dla kolejności końcowej, chyba że jest związane z określonym mechanizmem ograniczania liczby wierszy lub inną konstrukcją przewidzianą przez dany silnik SQL. W praktyce czytelniejszy jest schemat, w którym najpierw następuje połączenie zbiorów, a później filtrowanie, sortowanie albo dalsze grupowanie.

• Każda część UNION ALL powinna zwracać zgodną liczbę kolumn.
• Typy danych w odpowiadających sobie kolumnach powinny być kompatybilne.
• Aliasom i nazwom kolumn warto nadać spójne znaczenie.
• ORDER BY najczęściej umieszcza się na końcu całego zapytania.

UNION ALL — typowe problemy i błędy w zapytaniach

Jednym z częstych problemów jest niezamierzone zwielokrotnienie danych. Może do niego dojść, gdy dwa zakresy dat nachodzą na siebie albo gdy ten sam rekord jest pobierany z kilku źródeł. Przykładem jest połączenie danych za cały rok z osobnym zapytaniem dotyczącym ostatniego miesiąca tego samego roku. W takim układzie grudniowe rekordy mogą pojawić się ponownie. Nie jest to wada operatora, lecz skutek przyjętych warunków filtrowania.

Innym błędem bywa łączenie kolumn o podobnym wyglądzie, lecz odmiennym znaczeniu. Numer klienta nie powinien trafiać do kolumny opisanej jako numer zamówienia tylko dlatego, że obie wartości są przechowywane jako liczby. SQL może zaakceptować taką konstrukcję, ale raport stanie się mylący. Przed użyciem UNION ALL powinno się sprawdzić nie tylko typy danych, lecz także sens biznesowy każdej pozycji.

Problemy mogą wynikać również z wartości NULL, różnych formatów dat oraz odmiennego sposobu zapisu tekstu. Dwa pozornie identyczne identyfikatory mogą różnić się spacją, wielkością liter albo ukrytym znakiem. W zależności od ustawień bazy danych takie wartości mogą zostać potraktowane jako różne. Jeżeli duplikaty mają być kontrolowane, można najpierw ujednolicić dane funkcjami odpowiednimi dla danego silnika, a dopiero później zdecydować, czy potrzebne jest UNION, UNION ALL, DISTINCT lub osobna agregacja.

Warto zwracać uwagę na wydajność. UNION ALL zwykle ogranicza koszt związany z usuwaniem duplikatów, ale nadal może wymagać odczytu dużych tabel. Pomocne bywają właściwe warunki WHERE, ograniczenie wybieranych kolumn oraz indeksy dopasowane do filtrów. Nadmiarowe użycie SELECT * zwiększa ilość przesyłanych danych i utrudnia kontrolę zgodności schematów. Przy zmianie struktury jednej z tabel zapytanie może przestać działać albo zacząć zwracać kolumny w innym znaczeniu.

UNION ALL w praktyce — bezpieczne budowanie zapytań

Przed skonstruowaniem zapytania dobrze jest określić, czy łączone zbiory opisują ten sam rodzaj obiektu. Jeżeli jedna tabela przechowuje bieżące zgłoszenia, a druga archiwalne, należy ustalić wspólny zestaw pól: identyfikator, status, datę, opis oraz źródło. Warto dodać kolumnę techniczną wskazującą pochodzenie rekordu. Dzięki temu po połączeniu można łatwo sprawdzić, z którego zbioru pochodzi dana pozycja i wykryć nieoczekiwane rozbieżności.

Dobrym zwyczajem jest testowanie każdej części osobno, a następnie porównanie liczby wierszy przed i po połączeniu. Jeżeli pierwszy SELECT zwraca 120 rekordów, a drugi 80, wynik UNION ALL powinien zawierać 200 wierszy, o ile zapytania nie są opakowane w dodatkową konstrukcję ograniczającą rezultat. Taki test nie rozstrzyga jeszcze, czy dane są poprawne, ale pozwala szybko zauważyć utratę rekordów lub przypadkowe powielenie całego zakresu.

Jeżeli wymagane jest zachowanie powtórzeń, ale jednocześnie potrzebne jest oznaczenie ich liczby, można zastosować późniejsze grupowanie. Po połączeniu zbiorów grupuje się dane według wybranych kolumn i oblicza liczbę wystąpień. Takie podejście pozwala odróżnić zwykłe powtórzenie od sytuacji, w której duplikat powinien zostać usunięty. Z kolei gdy celem jest wyłącznie szybkie zebranie danych do dalszego przetwarzania, pozostawienie wierszy w pierwotnej postaci może być właściwsze.

W raportach wieloźródłowych przydatne jest jawne rzutowanie typów. Daty, liczby i teksty powinny być sprowadzone do uzgodnionego formatu, zwłaszcza gdy dane pochodzą z tabel tworzonych w różnych okresach. Należy też świadomie ustalić, czy brak wartości ma być reprezentowany przez NULL, pusty tekst czy wartość domyślną. Takie decyzje wpływają na późniejsze filtrowanie, sortowanie i agregowanie.

Kiedy UNION ALL wymaga konsultacji w serwisie komputerowym

Problemy z zapytaniami SQL mogą być objawem trudniejszej awarii środowiska pracy: niestabilnego systemu, uszkodzonego nośnika, błędów pamięci, nieprawidłowych sterowników albo problemów z uruchamianiem narzędzi bazodanowych. Gdy pojawiają się samoczynne restarty, utrata plików, spowolnienie odczytu lub komunikaty o błędach, warto najpierw zabezpieczyć kopię danych i unikać wielokrotnego uruchamiania operacji zapisujących.

W sytuacji, w której nie można ustalić, czy przyczyną jest samo zapytanie, aplikacja czy komputer, pomocne może być przekazanie sprzętu do Warszawskiego Pogotowia Komputerowego 24/7. Przed dalszą pracą można przygotować opis błędu, fragment zapytania, wersję używanego programu oraz informację o tym, kiedy problem zaczął występować. Ułatwia to rozdzielenie błędu logicznego w UNION ALL od problemu technicznego wpływającego na działanie całego stanowiska.

Do konsultacji warto zgłosić się także wtedy, gdy wynik zapytania jest formalnie poprawny, lecz raporty pokazują niespójne liczby. W takim przypadku analizie powinny zostać poddane zakresy dat, relacje między tabelami, sposób przechowywania identyfikatorów oraz oczekiwanie, czy powtórzenia są pożądane. Dopiero po takim rozpoznaniu można zdecydować, czy właściwym rozwiązaniem pozostaje UNION ALL, czy też potrzebna jest deduplikacja, zmiana warunków filtrowania albo uporządkowanie źródeł danych.