Silnik Sql Server posiada kilka metod do pobierania daty i czasu. Część z nich jest już przestarzała i nie powinno się z nich korzystać. SQL Server 2008 wprowadził kilka dodatkowych funkcji: SYSDATETIME, SYSDATETIMEOFFSET, SYSUTCDATETIME. Wszystkie one pobierają czas z dokładnością do 100 nanosekund. Aby przekonać się co dokładnie zwracają najlepiej wywołać je:

select SYSDATETIME() as 'SYSDATETIME',SYSDATETIMEOFFSET() 'SYSDATETIMEOFFSET', SYSUTCDATETIME() as 'SYSUTCDATETIME';

Jak widać SYSDATETIEM zwraca po prostu systemowy czas (z dokładnością do 100 nanosekund). Z kolei SYSDATETIMEOFFSET oprócz czasu zwraca również przesunięcie strefy czasowej (w tym przypadku +2). Z kolei SYSUTCDATIME zwraca czas w systemie UTC.

Jeśli nie potrzebna jest nam aż tak wysoka dokładność lepiej skorzystać z funkcji GETDATE, GETDATEUTC lub CURRENT_TIMESTAMP. GETDATE i CURRENT_TIMESTAMP działają identycznie, różnią się wyłącznie nazwą oraz sposobem wywołania:

select GETDATE() as 'GETDATE',GETUTCDATE() as 'GETDATEUTC',CURRENT_TIMESTAMP as 'CURRENT_TIMESTAMP'

Prawdopodobnie wszyscy znają już klauzulę group by w zapytaniach SQL – nie stanowi żadnej rewelacji. Myślę jednak, że znacznie mniej popularniejszą klauzulą jest GROUPING SETS. Rozważmy następujące zapytanie:

select * from Products GROUP BY ProductCategory
union all
select * from Products GROUP BY ProductSubcategory

Zapytanie zwróci wiersze pogrupowane po kategorii produktu oraz podkategorii. Należy podkreślić, że grupowania wykonywane są niezależnie od siebie i nie mają charakteru hierarchicznego (tak jak to byłoby w przypadku umieszczenia kolumn w jednym GROUP BY). Używając Gruping Sets, powyższe zapytanie można zapisać:

select * from Products GROUP BY  GROUPING SETS ((ProductCategory),(ProductSubcategory))

Podobnie zapytanie:

select * from Products GROUP BY ProductCategory,ProductSubcategory;

można zastąpić:

select * from Products GROUP BY GROUPING SETS ((ProductCategory,ProductSubcategory));

Ponadto w nawiasach można wykorzystać ROLL UP oraz CUBE.

Dzisiejszy post ma charakter raczej ciekawostki– w praktyce nic przydatnego nie wnosi:). Wiemy, że wartości NULL mają specjalne znaczenie – podstawowe operacje matematyczne zachowują się inaczej niż na zwykłych liczbach. Podobnie jest z porównywaniem NULL ponieważ służy do tego specjalny operator (IS NULL). Istnieje jednak w SQL Server zmienna, której ustawienie pozwala porównywać wartości NULL za pomocą klasycznych operatorów ‘<>==’. Rozważmy następujące zapytanie:

select * from Persons WHERE FirstName is null;

Ustawiając zmienną ANSI_NULLS na OFF można wykorzystać do tego celu operator ‘=’:

SET ANSI_NULLS off
select * from Persons where FirstName=null

Powyższe dwa fragmenty kodu działają identycznie. Bez ustawienia ANSI_NULLS na off zapytanie zwróciłoby zero wierszy ponieważ standardowo do porównywania NULL’i służy wyłącznie operator IS NULL.

W praktyce jednak uważam, że eleganckim rozwiązaniem jest wykorzystywanie is null zamiast kombinowania ze zmienną ANSI_NULLS. Post miał na celu wyłącznie pokazanie alternatywy :).

Czasami warto sprawdzić, czy wartości w podanych kolumnach zostały zmienione. Najłatwiejszym sposobem jest porównanie sumy kontrolnej. Jeśli stara wartość jest różna od aktualnej oznacza to, że któreś pole zostało zmienione. W T-SQL służy do tego funkcja CHECKSUM_AGG:

select CHECKSUM_AGG(Credit) from Persons GROUP BY Persons

Podobną funkcją jest CHECKSUM – liczy sumę kontrolną, jednak dla każdego wiersza a nie dla całych grup.

W SQL Server istnieje kilka narzędzi pozwalających określić wydajność wykorzystywanych zapytań. Podstawowym i najbardziej chyba znanym jest SQL Server Profiler. Można go włączyć z poziomu Sql Server Management Studio (menu główne->Tools->Sql Server Profiler). Po uruchomieniu pojawi się okienko w którym można określić m.in. zdarzenia, które powinny być monitorowane.

Następnie aby rozpocząć analizę należy wybrać Start Selected Trace (ikonka zielonej strzałki w ToolBar). Od tego momentu wszelkie zapytania wykonywane przez serwer bazodanowy będą wyświetlane w raporcie.

Podstawowa konfiguracja Profiler’a wyświetla m.in.:

1. nazwę zdarzenia,
2. treść zapytania,
3. źródło zdarzenia (np. zewnętrzna aplikacja lub Management Studio),
4. zużycie procesora,
5. liczbę operacji odczytu,
6. liczbę operacji zapisu,
7. czas trwania zdarzenia (czyli np. wykonania zapytania),
8. czas rozpoczęcia i zakończenia.

Jeśli któraś z metryk jest zbyt wysoka należy zastanowić się nad optymalizacja bazy lub zapytań. Na przykład w sytuacji gdy liczba odczytów jest zbyt wysoka można spróbować stworzyć dodatkowe indeksy. Warto regularnie uruchamiać profiler i monitorować ruch – pozwoli to zachować maksymalną wydajność. Szczególnie istotnymi pomiarami są te dokonywane już w realnym środowisku, na prawdziwych użytkownikach, ponieważ odzwierciedlają one najbardziej sposób wykorzystania aplikacji.

Często zdarza się, że mamy dwie takie same bazy: jedną lokalną do testów oraz drugą produkcyjną, umieszczoną na zdalnym hoście. Rozwijając aplikację, naturalne jest, że będziemy zmuszeni modyfikować bazę danych (dodanie nowych tabel, kolumn itp.). Wgrywając nową wersję na serwer łatwo zapomnieć o dokonanych zmianach na bazie. Na szczęście istnieją programy, które pozwolą nam zsynchronizować obydwie struktury. Jednym z nich jest dbForge Schema Compare for SQL Server.

Po uruchomieniu programu i wybraniu opcji “New Schema Comparison” określamy parametry baz (loginy, hasła, adresy).

Po dokonaniu porównania (przycisk Compare) zostanie wyświetlony szczególny raport:

Łatwo przejrzeć, które tabele się różnią oraz oczywiście ostatecznie zsynchronizować je.

Zasadniczą wadą programu jest fakt, że jest on płatny:). Można oczywiście ściągnąć wersję trialową. Jeśli ktoś zna jakieś darmowe alternatywy to proszę o sugestie w komentarzach.