REAL

REAL to czteroBajtowy typ zmiennoprzecinkowy SQL Server o mniejszej precyzji niż FLOAT.

REAL w języku SQL Server i jego podstawowe znaczenie

REAL to typ danych przeznaczony do przechowywania liczb zmiennoprzecinkowych, czyli takich, które mogą zawierać część ułamkową oraz bardzo duże albo bardzo małe wartości. W SQL Server zajmuje cztery bajty pamięci, dlatego bywa wybierany wtedy, gdy ważniejsze jest ograniczenie rozmiaru danych niż zachowanie maksymalnej dokładności obliczeń. W odróżnieniu od typu całkowitego nie przechowuje wyłącznie liczb bez części dziesiętnej. W odróżnieniu od typu opartego na arytmetyce dziesiętnej nie gwarantuje jednak dokładnego zapisu każdej wartości zapisanej w postaci dziesiętnej.

W praktyce REAL jest odpowiednikiem liczby zmiennoprzecinkowej pojedynczej precyzji. Oznacza to, że liczba bitów przeznaczonych na opis wartości jest ograniczona, a część z nich służy do określenia znaku, wykładnika i mantysy. Taki sposób zapisu pozwala uzyskać szeroki zakres wartości przy niewielkim zużyciu miejsca, lecz powoduje, że liczba przechowywana w pamięci może nie być identyczna z liczbą wpisaną przez użytkownika. Różnica zwykle jest niewielka, ale może stać się istotna podczas porównań, sumowania wielu rekordów albo filtrowania danych według granicy.

Typ REAL występuje w zapytaniach, definicjach tabel, procedurach i wyrażeniach obliczeniowych. Może być używany do wartości pomiarowych, odczytów z urządzeń, współrzędnych, wyników obliczeń technicznych lub danych, dla których przybliżenie jest akceptowalne. Sam fakt, że wartość wygląda jak liczba z kilkoma miejscami po przecinku, nie oznacza jeszcze, że REAL będzie właściwym wyborem. Decyzję powinno się uzależnić od znaczenia danych i wymaganej dokładności.

REAL a FLOAT, DECIMAL i liczby całkowite

Najczęściej REAL porównuje się z FLOAT. W SQL Server FLOAT może działać z większą precyzją, zależnie od zadeklarowanego parametru, natomiast REAL odpowiada wariantowi o mniejszej precyzji i stałym zapotrzebowaniu na cztery bajty. FLOAT bywa przydatny przy obliczeniach naukowych lub danych o szerokim zakresie, lecz większy rozmiar nie oznacza automatycznie dokładności dziesiętnej. Oba typy korzystają z reprezentacji binarnej, dlatego przy pewnych wartościach pojawiają się zaokrąglenia.

DECIMAL oraz NUMERIC stosuje się wtedy, gdy znaczenie ma kontrolowana liczba cyfr przed i po separatorze dziesiętnym. Takie typy są zwykle odpowiedniejsze dla kwot, rozliczeń, stawek, podatków, wyników księgowych i innych danych, w których nawet mała różnica może zmienić rezultat. REAL lepiej pasuje do danych pomiarowych lub obliczeń, w których wynik jest z natury przybliżony. Wybór typu nie powinien być dokonywany wyłącznie na podstawie nazwy kolumny. Należy uwzględnić sposób zapisu, późniejsze operacje oraz sposób prezentacji wyniku.

Liczby całkowite, takie jak INT czy BIGINT, nie przechowują części ułamkowej. Jeżeli do kolumny typu REAL zostanie przypisana wartość całkowita, zostanie ona zapisana w formacie zmiennoprzecinkowym, a nie jako klasyczna liczba całkowita. Przy konwersji w drugą stronę może dojść do utraty części ułamkowej albo do zmiany wartości wynikającej z zaokrąglenia. Szczególną uwagę należy zwrócić na mieszanie typów w jednym wyrażeniu, ponieważ SQL Server stosuje reguły pierwszeństwa typów i może samodzielnie wykonać konwersję.

Warto odróżnić dokładność od zakresu. REAL może reprezentować wartości o dużej rozpiętości, ale nie wszystkie cyfry takiej wartości będą zachowane. Typ dziesiętny może przechować mniej różnorodny zakres, lecz zapewnia przewidywalną liczbę cyfr znaczących w określonym układzie. Z tego powodu nie istnieje jeden uniwersalny typ właściwy dla wszystkich kolumn zawierających liczby.

REAL i typowe problemy z zaokrągleniami

Najczęstszym problemem jest porównywanie wartości REAL za pomocą operatora równości. Dwie liczby, które po wyświetleniu wyglądają tak samo, mogą mieć nieco różne reprezentacje binarne. W rezultacie warunek taki jak porównanie kolumny z wartością zapisaną w zapytaniu może nie zwrócić oczekiwanego rekordu. Dotyczy to zwłaszcza wyników działań arytmetycznych, konwersji z tekstu oraz wielokrotnego dodawania i odejmowania.

Bezpieczniejszym podejściem jest porównywanie z tolerancją. Zamiast wymagać identyczności bit po bicie, można sprawdzić, czy różnica między wartościami mieści się w ustalonym przedziale. Tolerancja powinna wynikać z zastosowania, jednostki pomiaru i dopuszczalnego błędu, a nie z przypadkowo przyjętej liczby. W innym przypadku filtr może pomijać rekordy, które z punktu widzenia użytkownika powinny zostać uznane za równe.

Problemem bywa również zaokrąglanie dopiero podczas prezentacji. Zmiana formatu wyświetlania do dwóch miejsc po przecinku nie zmienia automatycznie wartości zapisanej w kolumnie. Może jedynie zmienić jej wygląd w raporcie lub wyniku zapytania. Jeżeli wartość ma zostać trwale zaokrąglona, trzeba wykonać jawne działanie i świadomie zaakceptować utratę części informacji. W przeciwnym razie kolejne obliczenia nadal będą korzystały z pierwotnego przybliżenia.

Nie należy też zakładać, że kolejność operacji nie ma znaczenia. Przy liczbach zmiennoprzecinkowych suma wykonywana w innej kolejności może różnić się od poprzedniego wyniku, szczególnie gdy w zbiorze występują wartości o bardzo różnych rozmiarach. Znaczenie mają także konwersje między REAL, FLOAT i DECIMAL. Jawne określenie typu w kluczowych miejscach zapytania ułatwia kontrolę rezultatu i ogranicza ryzyko niezamierzonego przekształcenia.

REAL w tabelach, zapytaniach i aplikacjach

Przy projektowaniu tabeli warto ustalić, czy REAL opisuje pomiar, wynik modelu, współrzędną, wskaźnik czy wartość pomocniczą. Dla pomiarów należy określić jednostkę, możliwy zakres oraz wymaganą tolerancję. Sama definicja typu nie mówi, czy zapis jest poprawny z punktu widzenia dziedziny. Dobrą praktyką jest dokumentowanie założeń przy kolumnie, zwłaszcza gdy dane będą później eksportowane do innego programu.

Podczas wczytywania danych tekstowych warto sprawdzać nie tylko poprawność składni, lecz także sens wartości. Pusty tekst, separator dziesiętny używany w innym ustawieniu regionalnym, dodatkowe znaki oraz wartości spoza oczekiwanego zakresu mogą prowadzić do błędów konwersji albo nieoczekiwanych wyników. W zapytaniach raportowych pomocne jest jawne rzutowanie danych do typu odpowiadającego celowi obliczeń. Pozwala to ograniczyć sytuacje, w których jedna kolumna wpływa na wynik całego wyrażenia.

Indeksowanie kolumny REAL może być użyteczne, ale jego skuteczność zależy od sposobu formułowania warunku. Funkcja zastosowana bezpośrednio na kolumnie może utrudniać wykorzystanie indeksu. Podobny efekt może wystąpić, gdy po jednej stronie porównania znajdzie się typ wymagający konwersji. Oprócz samego typu danych należy więc przeanalizować plan wykonania, selektywność warunku i sposób filtrowania.

W aplikacji korzystającej z bazy danych warto ustalić, jak REAL jest mapowany na typ używany po stronie programu. Różnice w sposobie zaokrąglania, serializacji i formatowaniu mogą pojawić się przy przesyłaniu danych przez sterownik, interfejs programistyczny albo plik wymiany. Testy powinny obejmować zarówno typowe wartości, jak i liczby bardzo małe, bardzo duże, ujemne oraz takie, które mają długą część ułamkową.

REAL i moment zgłoszenia problemu do serwisu

Problemy z wartościami REAL mogą być objawem błędu w zapytaniu, nieprawidłowego mapowania danych, uszkodzenia systemu plików, problemu z pamięcią masową albo niestabilnej pracy komputera. Jeżeli wyniki obliczeń zmieniają się bez zmiany danych wejściowych, aplikacja zamyka się podczas zapisu lub odczytu, a pliki z bazą danych nie otwierają się poprawnie, warto zabezpieczyć kopię danych i zanotować moment wystąpienia problemu. Szczególnie ważne jest zachowanie komunikatów błędów oraz informacji o tym, czy problem dotyczy jednego programu, czy całego systemu.

Przed zgłoszeniem można sprawdzić, czy błąd powtarza się na tej samej operacji, czy występuje po określonej aktualizacji oraz czy dotyczy konkretnego pliku lub użytkownika. Nie powinno się jednak wielokrotnie uruchamiać naprawczych operacji na jedynej kopii danych. W przypadku podejrzenia awarii nośnika, przegrzewania albo błędów pamięci bezpieczniejsze jest ograniczenie pracy urządzenia i przygotowanie informacji dla osoby wykonującej diagnostykę.

W sprawach dotyczących komputera używanego do pracy z bazami danych, narzędziami programistycznymi lub aplikacjami analitycznymi można skorzystać z pomocy firmy Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem urządzenia warto opisać objawy, wskazać moment pojawienia się problemu i przygotować kopię zapasową, o ile komputer nadal działa stabilnie. Takie informacje ułatwiają rozdzielenie problemu sprzętowego od błędu konfiguracji, zapytania lub konwersji typu REAL.