UNIQUEIDENTIFIER

UNIQUEIDENTIFIER to typ danych przechowujący 16-bajtowy globalnie unikalny identyfikator GUID.

UNIQUEIDENTIFIER – czym jest ten typ danych

UNIQUEIDENTIFIER jest typem danych przeznaczonym do przechowywania identyfikatora o stałym rozmiarze 16 bajtów. W praktyce wartość taka jest zwykle przedstawiana jako GUID, czyli ciąg znaków zapisany w postaci kilku grup cyfr szesnastkowych, na przykład 6F9619FF-8B86-D011-B42D-00C04FC964FF. Zapis tekstowy ma 36 znaków wraz z łącznikami, natomiast wewnętrznie przechowywane jest 128 bitów informacji. Dzięki tak dużej przestrzeni możliwe jest tworzenie identyfikatorów z bardzo małym prawdopodobieństwem powtórzenia.

Typ UNIQUEIDENTIFIER wykorzystuje się przede wszystkim wtedy, gdy identyfikator rekordu powinien być unikalny nie tylko w obrębie jednej tabeli, lecz także między wieloma bazami danych, urządzeniami albo niezależnymi źródłami danych. W odróżnieniu od zwykłego numeru całkowitego wartość nie musi być nadawana kolejno. Może zostać wygenerowana wcześniej, jeszcze przed zapisaniem rekordu, a następnie użyta podczas synchronizacji lub wymiany danych.

W języku SQL wartość tego typu może być generowana funkcją NEWID(). Dostępna jest również funkcja NEWSEQUENTIALID(), która tworzy wartości o charakterze sekwencyjnym, co może ograniczać część problemów związanych z dopisywaniem rekordów do indeksu. Nie oznacza to jednak, że każda aplikacja powinna automatycznie korzystać z identyfikatorów GUID. Wybór powinien zależeć od sposobu generowania danych, rozmiaru tabel, rodzaju indeksów oraz tego, czy rekordy są tworzone w wielu niezależnych miejscach.

UNIQUEIDENTIFIER w porównaniu z numerem całkowitym

Najczęściej UNIQUEIDENTIFIER porównuje się z typami INT oraz BIGINT. Liczba całkowita zajmuje mniej miejsca i jest łatwa do odczytania, sortowania oraz ręcznego przekazywania w prostych formularzach. Kolejne identyfikatory, takie jak 1, 2, 3 lub 1001, są także wygodne podczas szybkiej analizy danych. W wielu klasycznych aplikacjach pojedyncza, centralnie zarządzana tabela może bez problemu korzystać z klucza całkowitego.

UNIQUEIDENTIFIER zapewnia natomiast większą niezależność źródeł danych. Dwa oddzielne moduły mogą wygenerować identyfikatory bez uzgadniania następnego numeru. Jest to przydatne podczas pracy bez stałego połączenia, importowania danych z kilku instalacji, tworzenia rekordów po stronie klienta oraz łączenia zbiorów, w których numery całkowite mogłyby się powtarzać. Identyfikator może powstać przed wysłaniem formularza, dzięki czemu rekord może być jednoznacznie rozpoznany również w kolejce oczekujących zmian.

Głównym kosztem jest większy rozmiar. Wartość UNIQUEIDENTIFIER zajmuje 16 bajtów, podczas gdy INT zajmuje 4 bajty, a BIGINT 8 bajtów. Różnica wpływa na rozmiar tabeli, indeksów oraz stron danych. Przy milionach rekordów może zwiększyć zapotrzebowanie na miejsce i liczbę operacji wejścia-wyjścia. Wartość zapisana losowo może również powodować częstsze podziały stron indeksu, zwłaszcza gdy jest kluczem głównym i jednocześnie indeksem klastrowym. Zastosowanie generowania sekwencyjnego, innego klucza porządkującego albo odpowiednio dobranej organizacji indeksów może ograniczyć ten efekt.

Nie powinno się też wybierać UNIQUEIDENTIFIER wyłącznie dlatego, że nazwa sugeruje pełną gwarancję unikalności w każdych warunkach. Kolizja jest skrajnie mało prawdopodobna przy prawidłowym generowaniu wartości, ale unikalność w konkretnej tabeli nadal powinna być chroniona przez ograniczenie UNIQUE albo klucz główny. Ochrona na poziomie bazy pozostaje potrzebna, ponieważ błąd aplikacji, ręczny import lub nieprawidłowe rzutowanie mogą doprowadzić do próby zapisania powtórzonej wartości.

UNIQUEIDENTIFIER a typowe problemy z danymi

Jednym z częstszych problemów jest mieszanie zapisu z łącznikami i bez łączników. System może przyjmować zarówno zapis tekstowy o długości 36 znaków, jak i zapis skrócony, lecz warstwa aplikacyjna powinna stosować jeden ustalony format. W przeciwnym razie wyszukiwanie, walidacja formularzy i logowanie zdarzeń stają się trudniejsze. Przy konwersji tekstu do UNIQUEIDENTIFIER należy obsługiwać błędne wartości, puste pola oraz dane zawierające dodatkowe spacje.

Problemy mogą wynikać także z niejawnych konwersji. Porównywanie kolumny typu UNIQUEIDENTIFIER z tekstem może wymusić dodatkową konwersję albo zakończyć się błędem, jeśli tekst nie przedstawia poprawnego identyfikatora. Bezpieczniejsze jest przekazanie parametru o właściwym typie oraz sprawdzenie danych na wejściu. Parametryzacja zapytań ogranicza ryzyko błędów składniowych i pomaga zachować przewidywalne działanie planu wykonania.

Osobnej uwagi wymaga sortowanie. Kolejność wartości tekstowych nie musi odpowiadać kolejności ich utworzenia. Nawet identyfikatory generowane w zbliżonym czasie mogą wyglądać jak całkowicie przypadkowe ciągi. Nie należy więc używać UNIQUEIDENTIFIER jako zastępstwa daty utworzenia, numeru kolejnego dokumentu ani wskaźnika kolejności operacji. Jeżeli potrzebna jest chronologia, należy przechowywać osobną kolumnę z datą i czasem albo oddzielny numer porządkowy.

W relacjach między tabelami kolumny klucza głównego i klucza obcego powinny mieć zgodne typy oraz zgodne właściwości. Zmiana jednego pola z INT na UNIQUEIDENTIFIER bez aktualizacji wszystkich powiązanych tabel może doprowadzić do błędów podczas zapisu, problemów z migracją i nieczytelnych zależności. Przed zmianą schematu należy sprawdzić indeksy, ograniczenia, procedury, widoki, raporty i kod aplikacji korzystający z danego identyfikatora.

UNIQUEIDENTIFIER – praktyczne wskazówki stosowania

Przed wyborem typu warto określić, gdzie i kiedy powstaje identyfikator. Jeśli wszystkie rekordy są tworzone w jednym miejscu, a najważniejsze są małe indeksy i prosty odczyt, typ całkowity może być wystarczający. Jeśli dane są tworzone niezależnie, przesyłane partiami lub łączone pochodzą z wielu źródeł, UNIQUEIDENTIFIER może uprościć uzgadnianie kluczy.

• Warto ustalić jeden sposób generowania identyfikatora i stosować go konsekwentnie w całej aplikacji.
• Warto używać klucza głównego lub ograniczenia unikalności, aby baza odrzucała powtórzone wartości.
• Warto rozważyć generowanie sekwencyjne, gdy GUID jest często dopisywany do indeksu i występują podziały stron.
• Warto unikać pokazywania identyfikatora użytkownikom, jeśli prostszy numer referencyjny poprawi czytelność dokumentu.
• Warto przechowywać datę utworzenia osobno, ponieważ UNIQUEIDENTIFIER nie jest znacznikiem czasu.
• Warto testować importy i synchronizację na danych zawierających wartości poprawne, puste, niepełne oraz powtórzone.

Podczas projektowania interfejsu można rozdzielić identyfikator techniczny od identyfikatora prezentowanego człowiekowi. UNIQUEIDENTIFIER pozostaje wtedy stabilnym kluczem używanym przez aplikację, a osobne pole może zawierać numer zamówienia, symbol zgłoszenia albo kod dokumentu. Takie rozwiązanie ułatwia komunikację, ponieważ długi ciąg znaków nie musi być przepisywany przez użytkownika podczas kontaktu z obsługą.

Warto również pamiętać o bezpieczeństwie. Trudny do odgadnięcia identyfikator nie zastępuje kontroli dostępu. Sam fakt, że adres zawiera GUID, nie powinien decydować o możliwości odczytu lub zmiany rekordu. Uprawnienia muszą być sprawdzane niezależnie, a identyfikatory nie powinny ujawniać informacji o liczbie rekordów ani kolejności operacji.

UNIQUEIDENTIFIER – kiedy zgłosić się do serwisu

Wsparcie serwisowe może być przydatne, gdy po zmianie schematu pojawiają się błędy konwersji, niedziałające relacje między tabelami, spowolnienie zapisu albo problemy z indeksami. Szczególnej uwagi wymagają sytuacje, w których aplikacja wcześniej korzystała z numerów całkowitych, a następnie zaczęła używać UNIQUEIDENTIFIER. Należy wtedy przeanalizować migrację danych, zgodność parametrów, klucze obce, procedury oraz kopie zapasowe.

W Warszawie takie prace może realizować Warszawskie Pogotowie Komputerowe 24/7, szczególnie gdy problem z bazą współwystępuje z niestabilnością systemu, błędami dysku, uszkodzeniem profilu użytkownika lub kłopotami z uruchamianiem aplikacji. Przed przekazaniem urządzenia warto przygotować opis objawów, moment pojawienia się problemu oraz informację o ostatnich zmianach w programie lub bazie. Nie należy usuwać plików danych ani wykonywać przypadkowych napraw, jeżeli może to utrudnić późniejsze odzyskanie informacji.

W przypadku błędów związanych z UNIQUEIDENTIFIER przydatne jest zabezpieczenie kopii bazy oraz dzienników aplikacji, o ile można to zrobić bez nadpisywania oryginalnych danych. Analiza powinna obejmować komunikat błędu, przykładową wartość identyfikatora, typ kolumny, definicję indeksu i sposób, w jaki rekord został utworzony. Tak zebrane informacje ułatwiają odróżnienie problemu z formatem wartości od problemu z wydajnością, migracją lub integralnością danych.