Tabela lokalna tymczasowa

Tabela lokalna tymczasowa jest widoczna wyłącznie w obrębie sesji, która ją utworzyła.

Tabela lokalna tymczasowa jako obiekt sesyjny

Tabela lokalna tymczasowa to pomocnicza struktura danych tworzona na czas wykonywania określonego zadania w bazie danych. Jej najważniejszą cechą jest ograniczony zakres widoczności: obiekt pozostaje dostępny dla sesji, która go utworzyła, natomiast inne połączenia nie powinny mieć do niego bezpośredniego dostępu. Dzięki temu można przechowywać dane pośrednie bez wprowadzania ich do trwałego schematu bazy. Takie rozwiązanie bywa przydatne podczas wieloetapowych zapytań, przygotowywania zestawień, filtrowania dużych zbiorów oraz porządkowania logiki procedur.

Określenie „lokalna” odnosi się przede wszystkim do zasięgu obiektu, a „tymczasowa” do jego przeznaczenia oraz cyklu życia. Nie chodzi wyłącznie o to, że rekordy będą używane krótko. Istotne jest również to, że tabela nie ma być stałym elementem modelu danych. Zwykle zostaje usunięta po zakończeniu sesji, po wykonaniu jawnej instrukcji usuwającej obiekt albo po zakończeniu konkretnej procedury, zależnie od używanego systemu i przyjętej składni.

W praktyce tabela lokalna tymczasowa może pełnić rolę bufora pomiędzy kolejnymi etapami obliczeń. Najpierw trafiają do niej rekordy wybrane według jednego kryterium, później są wzbogacane o informacje z kolejnych tabel, a na końcu służą do wygenerowania raportu lub aktualizacji innego zbioru. Taki podział ułatwia analizę zapytania, ponieważ każdy etap może zostać sprawdzony osobno.

Tymczasowa tabela lokalna a inne sposoby przechowywania danych

Warto odróżnić tabelę lokalną tymczasową od tabeli trwałej. Tabela trwała jest częścią schematu i pozostaje dostępna po zamknięciu połączenia, o ile nie zostanie usunięta przez uprawnionego użytkownika lub proces administracyjny. Tabela lokalna tymczasowa ma znacznie węższy zakres zastosowania. Jej zawartość jest przeznaczona dla bieżącego przebiegu pracy, a nie dla wielokrotnego korzystania przez wszystkie sesje.

Innym rozwiązaniem jest zmienna tabelaryczna albo konstrukcja podobna do wspólnego wyrażenia tabelarycznego. Zmienna tabelaryczna bywa wygodna przy niewielkich zbiorach danych i prostym przetwarzaniu, natomiast tabela tymczasowa może lepiej sprawdzać się przy dłuższym ciągu operacji, indeksowaniu danych pośrednich lub wielokrotnym odwoływaniu się do tego samego wyniku. Wspólne wyrażenie tabelaryczne z reguły istnieje tylko w ramach jednego polecenia, dlatego nie zastępuje obiektu wykorzystywanego przez kilka następujących po sobie instrukcji.

Nie należy również utożsamiać tabeli lokalnej tymczasowej z tabelą współdzieloną przez wiele połączeń. W zależności od systemu może istnieć wariant globalny, widoczny dla innych sesji, albo obiekt zapisujący dane w zwykłej tabeli roboczej. Wybór powinien wynikać z wymaganej izolacji, czasu życia danych oraz sposobu uruchamiania procesu. Jeżeli dane nie mogą być odczytywane przez inne sesje, właściwy zakres widoczności ma znaczenie równie duże jak sama struktura kolumn.

Różnice mogą dotyczyć także transakcji. W jednym środowisku utworzenie obiektu może być niezależne od zatwierdzania rekordów, w innym operacje na tabeli mogą podlegać zasadom transakcyjnym podobnym do zasad obowiązujących dla tabel trwałych. Z tego powodu składnię, zachowanie po wycofaniu transakcji oraz moment automatycznego usunięcia należy sprawdzić w dokumentacji konkretnego silnika bazy danych.

Tabela tymczasowa lokalna i typowe problemy

Najczęstszy problem wynika z błędnego założenia, że obiekt utworzony w jednej sesji będzie dostępny także w innej. Próba odczytu z osobnego połączenia może zakończyć się błędem braku obiektu, nawet jeśli nazwa i definicja tabeli są poprawne. Taka sytuacja pojawia się między innymi wtedy, gdy aplikacja otwiera nowe połączenie dla każdego etapu pracy, a tabela została utworzona w połączeniu wcześniejszym.

Drugą trudnością jest niejawne rozdzielenie sesji przez narzędzie pośredniczące. Pula połączeń może zwrócić inne połączenie niż to, w którym utworzono tabelę. Z punktu widzenia aplikacji wszystkie połączenia mogą wyglądać podobnie, ale dla lokalnego obiektu są odrębnymi środowiskami. W takim przypadku należy dopilnować, aby utworzenie tabeli, zapis danych i późniejsze odczyty odbywały się w ramach tej samej sesji albo aby zastosowano rozwiązanie o szerszym zasięgu.

Problemy mogą dotyczyć również kolizji nazw. Dwa niezależne połączenia mogą utworzyć lokalne obiekty o tej samej nazwie, ponieważ każdy z nich widzi własny obiekt. Nie oznacza to jednak, że można bez ograniczeń przenosić odwołania pomiędzy sesjami. Błędy powstają też przy wielokrotnym uruchamianiu skryptu, gdy procedura próbuje utworzyć tabelę, która już istnieje w bieżącym połączeniu. Pomaga stosowanie jednoznacznych nazw, kontrola istnienia obiektu oraz jawne usuwanie tabeli po zakończeniu pracy.

Wydajność nie zawsze będzie lepsza tylko dlatego, że użyto tabeli tymczasowej. Przy małej liczbie rekordów koszt utworzenia, wypełnienia i ewentualnego indeksowania może przewyższyć korzyści. Przy większych zbiorach trzeba zwrócić uwagę na plan zapytania, selektywność filtrów, typy danych i liczbę wykonywanych operacji. Nieprawidłowo dobrane indeksy mogą zwiększyć czas zapisu, a brak indeksu na kolumnie często wykorzystywanej w łączeniu może spowodować kosztowne skanowanie danych.

Praktyczne wskazówki dla tabeli lokalnej tymczasowej

Przed utworzeniem obiektu warto określić, jak długo dane będą potrzebne i kto ma je odczytywać. Jeżeli wynik będzie wykorzystywany wyłącznie w jednym poleceniu, prostsze może być użycie podzapytania lub wspólnego wyrażenia tabelarycznego. Jeżeli dane mają przejść przez kilka etapów, tabela tymczasowa zapewnia czytelny punkt pośredni, który można sprawdzić, policzyć i porównać z oczekiwanym rezultatem.

Definicja powinna zawierać tylko potrzebne kolumny. Ograniczenie liczby pól zmniejsza ilość zapisywanych danych i ułatwia kontrolę typów. Należy unikać automatycznego kopiowania całej struktury źródłowej, jeśli dalsze kroki korzystają tylko z kilku atrybutów. Warto także jawnie określać typy danych, długości tekstu, możliwość wystąpienia wartości pustej oraz zasady zaokrąglania liczb.

Dobrym zwyczajem jest sprawdzenie liczby rekordów po każdym istotnym etapie. Pomaga to wykryć nieoczekiwane powielenia wynikające z łączeń, utratę danych po zastosowaniu filtra albo błędne dopasowanie kluczy. Przy procesach uruchamianych automatycznie należy rejestrować najważniejsze informacje diagnostyczne, lecz bez zapisywania w logach danych wrażliwych. Można również dodać komentarz opisujący źródło danych i przewidywany czas życia tabeli.

W przypadku procedur wielokrotnie uruchamianych w tej samej sesji należy zaplanować obsługę ponownego wykonania. Tabela może zostać wyczyszczona przed ponownym napełnieniem albo usunięta i utworzona od nowa, zależnie od wymagań procesu. Przy zamykaniu aplikacji warto zweryfikować, czy połączenie jest zwalniane prawidłowo. Nieprawidłowo zarządzane sesje mogą utrudniać diagnozowanie błędów i powodować niepotrzebne zajmowanie zasobów do czasu automatycznego zakończenia połączenia.

Przed zmianą istniejącego zapytania zaleca się wykonanie kopii skryptu, sprawdzenie planu wykonania oraz przetestowanie przypadku pustego wyniku, pojedynczego rekordu i większego zbioru. Dzięki temu można odróżnić błąd zakresu widoczności od błędu logiki biznesowej lub problemu z wydajnością.

Kiedy zgłosić tabelę lokalną tymczasową do serwisu

Wsparcie serwisowe może być potrzebne, gdy aplikacja losowo zgłasza brak tabeli, wyniki różnią się pomiędzy uruchomieniami albo zapytanie działa tylko po ręcznym wykonaniu kilku poleceń. Szczególnej uwagi wymaga sytuacja, w której problem pojawił się po zmianie sterownika, aktualizacji programu, konfiguracji połączeń lub wdrożeniu puli sesji. Wtedy przyczyną może być nie sama definicja tabeli, lecz sposób utrzymywania połączenia z bazą.

Do zgłoszenia warto dołączyć opis kolejności operacji, fragment odpowiedzialny za utworzenie obiektu, komunikat błędu, informacje o tym, czy aplikacja korzysta z jednego połączenia, oraz przykład danych, na których problem można odtworzyć. Nie powinno się przekazywać haseł, pełnych danych osobowych ani nieograniczonych zrzutów bazy. Wystarczający, anonimowy przykład często pozwala szybciej ustalić, czy kłopot wynika z zakresu sesji, transakcji, nazw obiektów, typów danych czy planu wykonania.

W Warszawie analizę takich problemów sprzętowych i programowych można zlecić firmie Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem urządzenia lub środowiska do sprawdzenia zaleca się opisanie objawów i wykonanych już czynności, ponieważ ułatwia to odtworzenie kolejności zdarzeń. Po rozpoznaniu przyczyny można zdecydować, czy potrzebna jest korekta konfiguracji, poprawa zapytania, uporządkowanie połączeń, czy też dodatkowa kontrola komputera, na którym uruchamiane jest oprogramowanie.