Zgodność typów w UNION

Zgodność typów w UNION jest wymagana — kolumny łączonych zapytań muszą mieć porównywalne typy danych.

Na czym polega zgodność typów w UNION

Operator UNION służy do połączenia wyników dwóch lub większej liczby zapytań SELECT w jeden zbiór wierszy. Każde z tych zapytań musi zwracać taką samą liczbę kolumn, a kolumny znajdujące się na tych samych pozycjach muszą mieć typy danych, które można ze sobą porównać albo połączyć. Pierwsza kolumna pierwszego zapytania jest więc zestawiana z pierwszą kolumną kolejnego zapytania, druga z drugą i tak dalej. Nazwy kolumn wyniku są zazwyczaj ustalane na podstawie pierwszego zapytania.

Zgodność nie oznacza, że typy muszą być zapisane identycznie w definicji tabeli. Liczba całkowita może zostać połączona z innym typem liczbowym, jeśli używany silnik potrafi zastosować reguły konwersji. Podobnie typy tekstowe o różnych długościach często mogą wystąpić w jednej kolumnie wyniku. Problem pojawia się wtedy, gdy wartości mają nieporównywalne znaczenie lub gdy automatyczna konwersja nie jest możliwa, na przykład przy próbie połączenia wartości daty z nieprzekształconym typem logicznym albo z tekstem zawierającym niepoprawne dane.

Typowe błędy w łączonych zapytaniach

Najprostszym błędem jest różna liczba kolumn. Zapytanie SELECT id, nazwa FROM produkty nie może zostać połączone operatorem UNION z zapytaniem SELECT id, nazwa, cena FROM archiwum, ponieważ pierwsza część zwraca dwie kolumny, a druga trzy. Aby wyrównać strukturę, trzeba usunąć nadmiarową kolumnę albo dodać brakującą wartość, na przykład NULL AS cena. W praktyce warto nadać takiej wartości jawny typ, jeśli silnik lub dalsza część zapytania wymaga jednoznacznego określenia typu.

Druga grupa problemów dotyczy typów na tej samej pozycji. Przykładowo pierwsze zapytanie może zwracać identyfikator jako liczbę, a drugie jako tekst. Czasem silnik wykona niejawną konwersję, ale jej wynik zależy od reguł danego systemu, ustawień oraz zawartości danych. Wartość tekstowa '123' może zostać przekształcona do liczby, natomiast tekst 'brak' spowoduje błąd, jeśli konwersja do typu liczbowego zostanie wymuszona. Należy też uważać na kolejność kolumn: zgodność jest oceniana według pozycji, a nie według nazw ani podobieństwa aliasów.

Jawne konwersje i wpływ UNION na wynik

Gdy typy nie są jednoznacznie zgodne, należy użyć jawnego rzutowania wartości do wspólnego typu. W zależności od silnika SQL stosuje się do tego funkcje lub składnię takie jak CAST, a w niektórych implementacjach również CONVERT. Przykładowo oba zapytania mogą zwracać identyfikator jako tekst: CAST(id AS VARCHAR(20)). Jawna konwersja dokumentuje zamiar autora i ogranicza ryzyko, że silnik wybierze nieoczekiwany typ pośredni albo spróbuje przekształcić wartości w niekorzystnej kolejności.

Trzeba pamiętać, że typ końcowej kolumny wyniku jest ustalany na podstawie reguł danego silnika, zwykle z uwzględnieniem priorytetu typów, ich długości, precyzji i skali. Ma to znaczenie dla liczb dziesiętnych, tekstów oraz dat. Połączenie kolumn tekstowych o różnych długościach może doprowadzić do wybrania określonej długości wyniku, a połączenie typów liczbowych o różnej precyzji może zmienić sposób przechowywania części ułamkowej. Jeśli wynik ma być używany przez aplikację, raport albo eksport do pliku, typy należy sprawdzić również na granicy programu, ponieważ sterownik może mapować je na inne typy języka programowania.

UNION usuwa duplikaty z połączonego wyniku, natomiast UNION ALL zachowuje wszystkie wiersze. Oba operatory wymagają zgodności struktury kolumn, ale wybór między nimi wpływa na wydajność i znaczenie danych. Jeżeli dwa źródła zawierają ten sam rekord i nie powinien on wystąpić dwukrotnie, usuwanie duplikatów jest częścią logiki zapytania. Jeżeli źródła opisują niezależne zdarzenia, użycie UNION może niezamierzenie ukryć powtarzające się wiersze.

Diagnostyka problemu w praktycznym zapytaniu

Podczas diagnozowania błędu należy najpierw rozpisać kolumny wszystkich gałęzi operatora w tej samej kolejności. Dla każdej pozycji trzeba sprawdzić typ źródłowy, możliwość konwersji, długość tekstu, precyzję liczby oraz sposób obsługi wartości NULL. Pomocne jest uruchomienie każdego zapytania osobno i sprawdzenie jego metadanych w narzędziu klienckim lub dokumentacji konkretnego silnika. Następnie warto dodać jawne aliasy i CAST w każdej gałęzi, zamiast pozostawiać wybór typu przypadkowej inferencji.

Przykładowa bezpieczna struktura może sprowadzać identyfikator do wspólnego typu tekstowego, nazwę do ustalonego typu znakowego, a brakującą wartość ceny zastępować typowanym NULL. Nie należy natomiast maskować błędu przez konwersję wszystkiego do tekstu, jeśli wynik ma później służyć do sortowania, obliczeń lub filtrowania liczbowego. Takie rozwiązanie może sprawić, że wartości będą sortowane leksykograficznie, więc ciąg 10 może znaleźć się przed 2.

Po poprawieniu typów należy przetestować zapytanie na danych rzeczywistych, w tym na pustych wartościach, dużych liczbach, długich tekstach, niepoprawnych datach oraz rekordach powtarzających się w obu źródłach. Sam fakt, że zapytanie się kompiluje, nie potwierdza poprawności przepływu danych. Trzeba jeszcze sprawdzić, czy wartości nie są obcinane, zaokrąglane albo zmieniane podczas konwersji oraz czy zastosowanie UNION zamiast UNION ALL nie usuwa wierszy wymaganych przez aplikację.