Kolejny milowy krok

SQL Server jest w trakcie poważnej przebudowy. Zostaną zmienione zarówno część administracyjna, jak i mechanizmy udostępniane programistom.

Dla programisty

Bodajże największa zmiana w Yukonie wiąże się z możliwością pisania specjalnych pakietów .Net, które są wykonywane bezpośrednio w procesie SQL Servera. Tylko od programisty zależy, czy napisze on "tradycyjną" procedurę przechowywaną w T-SQL czy też utworzy pakiet .Net. Zdaniem przedstawicieli Microsoftu to drugie rozwiązanie ma dwie podstawowe zalety. Po pierwsze, w niektórych przypadkach (np. w obliczeniach zmiennoprzecinkowych) programy .Net działają szybciej i są wygodniejsze w użyciu. Po drugie, programista może zadecydować, że np. komponent intensywnie wykorzystujący bazę danych będzie uruchamiany tak "blisko" serwera SQL, jak tylko możliwe. Programista lub administrator, wgrywając pakiet .Net, określa, jakie operacje może wykonać dany kod działający w procesie serwera. Ma do dyspozycji wzorce: safe, gdzie kod .Net ma dostęp tylko do zasobów SQL Server (ale już nie do pamięci i wątków); external, w którym kod może m.in. odwoływać się do funkcji systemu operacyjnego (w tym kryptograficznych); unsafe, w którym dozwolone jest każde działanie, włącznie z operacjami wejścia/wyjścia na plikach. Yukon nie jest bazą obiektową. Można natomiast, stosując pakiet .Net, zdefiniować własny typ danych, który np. zostanie wykorzystany do definicji kolumny w tabeli.

Pakiet .Net używany przez SQL Server jest zapisywany w bazie i umieszczany w kopii zapasowej razem z innymi elementami bazy. Integracja z .Net nie oznacza, że zostaną zarzucone prace nad T-SQL. Ten język nadal jest rozwijany. Na razie wiadomo że w Yukonie pojawi się typ varchar(max), o długości 2 GB, a także dodatkowa składnia pozwalająca oczekiwać na zakończenie wybranej operacji. Prawdopodobnie będzie też można definiować procedury wywoływane w momencie, gdy nastąpi określona zmiana danych (taki trigger z bardziej zaawansowanym warunkiem automatycznego wywołania). Procedura obsługi błędów będzie się opierać na schemacie wyjątków (try-catch-abort). Zmieni się też mechanizm rekompilacji procedur przechowywanych. W SQL 2000 była rekompilowana cała procedura. W Yukonie będzie rekompilowana tylko ta instrukcja, która uległa zmianie (lub ta, która z uwagi na zmianę warunków musi zostać zrekompilowana). Rozbudowano mechanizmy wsparcia dla XML. Yukon ma specjalny typ pola XML data, przeznaczony do przechowywania dokumentów XML. Dane można analizować albo jako "widok SQL", albo jako "widok XML" i bez żadnego ryzyka przełączać się między tymi sposobami prezentacji.

Narzędzie Query Analyzer zawiera edytor przypominający środowisko pracy dla programistów. Wyposażone jest w możliwości zwijania i rozwijania "ciała" skryptów czy procedur T-SQL. Podczas pisania kodu dostępny jest mechanizm automatycznego uzupełniania wyrażeń. Query Analyzer podpowiada zarówno nazwę procedury wbudowanej, jak i tabeli czy pola. W oknie tootip jest wyświetlana skrócona pomoc. Podobnie jak w Visual Studio.Net po prawej stronie jest wyświetlana na bieżąco pomoc kontekstowa. Skrypty mogą być umieszczone w narzędziu do kontroli wersji. Jeżeli w wyniku działania skryptu powstaje zbiór rekordów, wynik można od razu zapisać jako dokument XML. Tak jak poprzednio można podejrzeć plan wykonania kwerendy, ale w Yukonie można go zapisać jako dokument XML. Microsoft przewiduje, że pojawią się w przyszłości narzędzia analizujące tak zapisany plan wykonania (obecnie robi to de facto Database Tuning Wizard). Warto przypomnieć, że już od SQL Server w wersji 7.0 Microsoft zalecał stosowanie tzw. widoków informacyjnych, zamiast bezpośrednich kwerend do obiektów systemowych. W projekcie Yukon zmieniły się bazy systemowe, ale struktura widoków jest zgodna wstecz. Pojawiło się 100 nowych elementów opisujących dokładniej katalog SQL (strukturę obiektów w bazie itp.). Przedstawiciele Microsoftu zapewniają, że w Yukonie nie ma już kolumn oznaczonych w dokumentacji "tylko do użytku wewnętrznego".