MERGE

MERGE to polecenie SQL łączące wstawianie, aktualizację i usuwanie wierszy w jednej operacji względem tabeli źródłowej.

MERGE jako operacja warunkowego przetwarzania wierszy

MERGE jest poleceniem języka SQL służącym do wykonania różnych operacji na tabeli docelowej na podstawie porównania jej danych z tabelą albo wynikiem zapytania źródłowego. Dla każdego wiersza źródłowego ustalany jest wynik warunku dopasowania, zwykle zapisanego w klauzuli ON. Jeżeli istnieje odpowiadający mu wiersz w tabeli docelowej, można wykonać aktualizację. Jeżeli dopasowania nie ma, można wykonać wstawienie nowego wiersza. Niektóre implementacje pozwalają również usunąć wiersz po dopasowaniu, gdy spełniony zostanie dodatkowy warunek.

Ogólna idea MERGE przypomina połączenie operacji UPDATE i INSERT, ale dokładna składnia, dostępne klauzule oraz ograniczenia zależą od konkretnego silnika bazy danych. Samo użycie słowa MERGE nie gwarantuje identycznego zachowania w różnych systemach. Dokumentacja danego produktu określa między innymi, czy dozwolone jest usuwanie, jakie warunki można stosować przy poszczególnych akcjach oraz jak silnik reaguje na wielokrotne dopasowanie tego samego wiersza.

Warunek dopasowania i podział na akcje

Najważniejszym elementem MERGE jest warunek określający, kiedy wiersz źródłowy odpowiada wierszowi tabeli docelowej. W praktyce powinien on opierać się na kluczu głównym, kluczu unikatowym albo innym jednoznacznym identyfikatorze rekordu. Przykładowo, tabela źródłowa może zawierać identyfikator produktu i jego aktualną cenę, a tabela docelowa może przechowywać wcześniejszy stan tych samych produktów. Dopasowanie po identyfikatorze pozwala rozdzielić rekordy na przeznaczone do aktualizacji oraz na nowe rekordy przeznaczone do wstawienia.

Warunek ON nie powinien zastępować kontroli jakości danych. Jeżeli źródło zawiera dwa wiersze z tym samym kluczem, jeden rekord docelowy może pasować do więcej niż jednego wiersza źródłowego. W wielu implementacjach prowadzi to do błędu, ponieważ silnik nie może jednoznacznie ustalić kolejności lub wyniku aktualizacji. Przed wykonaniem MERGE warto więc sprawdzić unikatowość klucza w źródle oraz zgodność typów danych używanych w warunku porównania. Znaczenie mają także wartości NULL: porównanie z użyciem operatora równości nie uznaje dwóch wartości NULL za równe, dlatego warunek dopasowania wymaga świadomego zaprojektowania.

Akcje wykonywane po dopasowaniu powinny być rozdzielone logicznie. Aktualizacja może mieć własny warunek, na przykład ograniczać zmianę do rekordów, których wartość źródłowa jest nowsza. Wstawienie może obejmować tylko wiersze nieznalezione w tabeli docelowej. Usunięcie, jeżeli jest dostępne w danym silniku, powinno być stosowane ostrożnie, ponieważ błąd w warunku może usunąć dane zamiast jedynie uzupełnić brakujące rekordy.

Transakcja, ograniczenia i skutki uboczne

MERGE zwykle wykonuje logicznie wiele zmian w ramach jednej instrukcji, lecz szczegóły atomowości i poziomu izolacji wynikają z konfiguracji oraz zasad konkretnego silnika. Jeżeli operacja jest częścią jawnej transakcji, jej zatwierdzenie lub wycofanie powinno obejmować także inne powiązane instrukcje. Przy dużych zbiorach danych znaczenie mają blokady, indeksy oraz plan wykonania zapytania. Brak indeksu wspierającego warunek dopasowania może spowodować skanowanie tabeli i zwiększyć czas trwania operacji.

Na wynik MERGE wpływają ograniczenia tabeli docelowej. Klucz główny i indeksy unikatowe mogą odrzucić wstawienie duplikatu. Ograniczenie NOT NULL może zablokować akcję, jeżeli źródło nie dostarczy wymaganej wartości, a ograniczenie CHECK może odrzucić rekord niespełniający reguły biznesowej zapisanej w bazie. W zależności od silnika mogą zostać uruchomione również wyzwalacze reagujące na wstawianie, aktualizację albo usuwanie. Dlatego analiza skutków MERGE powinna obejmować nie tylko samą instrukcję, lecz także schemat tabeli, indeksy, wyzwalacze i zależności.

Szczególnej uwagi wymaga równoczesne wykonywanie MERGE przez kilka sesji. Dwie operacje mogą jednocześnie uznać ten sam klucz za nieobecny i spróbować go wstawić, co może zakończyć się konfliktem unikatowości albo innym wynikiem zależnym od mechanizmu współbieżności. Bezpieczeństwo takiego scenariusza zależy od poziomu izolacji, blokad i implementacji używanego systemu. Nie należy zakładać, że pojedyncza instrukcja automatycznie eliminuje wszystkie wyścigi między transakcjami.

Testowanie i kontrola poprawności wyniku

Przed uruchomieniem MERGE na danych produkcyjnych warto wykonać zapytanie odtwarzające sam warunek dopasowania. Pozwala to policzyć wiersze pasujące, niepasujące oraz potencjalnie wielokrotnie dopasowane. Przydatne jest także zapisanie kopii danych objętych zmianą albo użycie mechanizmu rejestrowania zmodyfikowanych wierszy, jeżeli dany silnik go udostępnia. Test powinien obejmować puste źródło, nowe rekordy, istniejące rekordy, zmienione wartości, duplikaty klucza i wartości NULL.

Nie każda operacja synchronizacji wymaga MERGE. Gdy logika jest prosta, oddzielne instrukcje UPDATE i INSERT mogą być łatwiejsze do przeanalizowania i monitorowania. Wybór zależy od wymagań silnika, oczekiwanej współbieżności, wielkości danych oraz potrzeby rozróżnienia liczby aktualizacji, wstawek i usunięć. Diagnostyka problemu z MERGE powinna rozpocząć się od odczytania dokładnego komunikatu błędu, sprawdzenia definicji tabel i indeksów oraz porównania rzeczywistego planu wykonania z zakładanym przepływem danych.

W przypadku nieprawidłowego wyniku należy ustalić, która akcja została wybrana dla konkretnego wiersza i jakie wartości były dostępne w źródle w chwili wykonania instrukcji. Pomocne jest uruchomienie tej samej logiki na kontrolnym zbiorze danych oraz porównanie stanu przed i po transakcji. Sama obecność poprawnej składni nie potwierdza poprawności synchronizacji: decydujące znaczenie mają jednoznaczność dopasowania, kompletność danych źródłowych, reguły ograniczeń i zachowanie używanego silnika SQL.