Widok sys.objects (typ FN

Obiekty typu FN w sys.objects to funkcje skalarne zdefiniowane przez użytkownika.

Jak rozpoznać funkcję skalarną w katalogu systemowym

W widoku sys.objects każdy obiekt bazy ma kolumnę type z dwuznakowym kodem oraz type_desc z opisem słownym. Wartość FN oznacza SQL_SCALAR_FUNCTION, czyli funkcję skalarną napisaną w języku T-SQL i zwracającą pojedynczą wartość. Warto odróżnić ją od pokrewnych kodów: IF to funkcja tablicowa wbudowana, złożona z jednej instrukcji SELECT, TF to funkcja tablicowa z ciałem wieloinstrukcyjnym, a FS i FT oznaczają odpowiedniki tworzone w kodzie zarządzanym. Treść funkcji odczytuje się z sys.sql_modules po kolumnie object_id albo funkcją OBJECT_DEFINITION, o ile nie została utworzona z opcją WITH ENCRYPTION.

Wpływ funkcji skalarnych na wydajność zapytań

To najważniejsza rzecz praktyczna związana z tym typem obiektu. Funkcja skalarna umieszczona w klauzuli SELECT albo WHERE we wcześniejszych wersjach silnika była wykonywana osobno dla każdego wiersza, poza planem zapytania, i nie pojawiała się w kosztach — zapytanie na milionie wierszy wywoływało ją milion razy, a plan wykonania wyglądał niewinnie. Dodatkowo obecność takiej funkcji blokowała zrównoleglenie całego zapytania. Nowsze wersje SQL Servera wprowadziły mechanizm wstawiania funkcji skalarnych w treść zapytania, działający jednak tylko przy odpowiednim poziomie zgodności bazy i tylko dla funkcji spełniających warunki — bez odwołań do tabel czasowych, bez zmiennych tabelarycznych, bez funkcji niedeterministycznych w ciele. Baza podniesiona z wersji sprzed lat często pozostaje na starym poziomie zgodności, przez co optymalizacja nie działa mimo nowego silnika.

Typowe kłopoty przy modyfikacji i wdrażaniu

Pierwszy to zależności: próba usunięcia funkcji użytej w definicji kolumny wyliczanej, ograniczenia CHECK albo widoku z indeksem kończy się błędem, a listę powiązań daje sys.sql_expression_dependencies. Drugi to opcja SCHEMABINDING — bez niej silnik nie gwarantuje stabilności definicji obiektów źródłowych, z nią z kolei nie da się zmienić typu kolumny w tabeli, do której funkcja się odwołuje. Trzeci dotyczy funkcji o tej samej nazwie w różnych schematach: wywołanie bez podania schematu trafia w obiekt zależny od domyślnego schematu użytkownika, więc ten sam kod daje różne wyniki dla różnych kont. Czwarty to funkcje pozostawione po nieudanej aktualizacji programu handlowego, wciąż obecne w bazie i wywoływane przez stare raporty.

Opieka nad bazami systemów sprzedażowych

Bazy wdrożeń handlowych po kilku latach zawierają warstwy dopisanych funkcji i widoków, często tworzonych przez różne osoby przy okazji raportów na zamówienie. Warszawskie Pogotowie Komputerowe inwentaryzuje takie środowiska przed migracją na nowy serwer albo przed aktualizacją wersji programu, żeby po przeniesieniu nie okazało się, że połowa zestawień przestała działać. Zajmujemy się instalacją i serwisem oprogramowania handlowego typu Subiekt, WAPRO i Comarch pracującego na SQL Server, razem z konfiguracją samego serwera i stacji roboczych w firmie.