Dlaczego na najwyższych platformach baz danych nie są dostępne typy liczb całkowitych bez znaku?

Bazy danych są zazwyczaj bardzo konfigurowalne przy różnych typach danych i niestandardowych długościach.

Zaskakuje mnie, gdy próbuję poszukać składni, aby użyć unsigned inttypów, które nie są dostępne z PostgreSQL i MS SQL Server. Wydaje się, że MySQL i Oracle.

Wydaje się to rażącym pominięciem z ich strony - następną najlepszą opcją perfomant jest długi / bigint (8-bajtowa liczba całkowita), ale może być zupełnie niepotrzebny! Czy ktoś wie, dlaczego zdecydowałby się nie uwzględniać natywnej obsługi bez znaku int?

sql-server postgresql datatypes

— Ehryk
źródło

Przenośne == standardowe zlecone. Norma C nie określa szerokości zwykłych liczb całkowitych lub długich, a jedynie minimalne zakresy reprezentowalnych liczb. Platformy z 16-bitowymi intami były kiedyś popularne. 64bit jest możliwy. 36 też (choć wymarły). 24 dzieje się (DSP). Jak często zdarza się, że masz dane, które pasują do 32-bitowych, ale nie 31, i że zmierzyłeś, że użycie zwykłych typów numerycznych daje ci hit wydajności?

— Mat

Zarówno SQL-Server, jak i Postgres mają NUMERIC(10)9.999.999.999

— liczbę

Z jednego powodu: nie są określone w standardzie SQL. Aby uzyskać dłuższą dyskusję dotyczącą Postgres, spójrz na tę dyskusję: postgresql.1045698.n5.nabble.com/… i to: postgresql.1045698.n5.nabble.com/…

— a_horse_with_no_name

Dla SQL Server jest wyjaśnienie

— Martin Smith,

@Mat Martwię się o to nie o wydajność, to 4 dodatkowe bajty x 153 miliony = ~ 612 dodatkowego zmarnowanego MB, wartości przekraczają 3 miliardy, ale nie 4 miliardy. Cyfra (10) ma oprócz wyników także 9 bajtów pamięci: msdn.microsoft.com/en-us/library/ms187746.aspx

— Ehryk

Jim Hogg z firmy Microsoft odpowiedział na ten problem następująco:

Są plusy i minusy. Z drugiej strony wydaje się, że to dobry sposób na uniknięcie pewnych błędów - sprawdzanie (podpisanej) wartości int ma wartość> 0. I zaryzykowałbym również stwierdzenie, że wiele zastosowań int odnosi się do liczb, które i tak nigdy nie powinny być ujemne . W kwestii podwojenia maksymalnej liczby wierszy? - prawda, ale powiedziałbym, że jest to mniej przekonujące.

Jeśli chodzi o minusy ... mieszanie podpisanych / niepodpisanych typów w C lub C ++ wydaje się, że powinno być dość proste. To nie jest. Otwiera małą pułapkę trudnych do znalezienia błędów - głównie ze względu na skomplikowane zasady dotyczące niejawnych promocji / poszerzeń. Niestety, SQL ma już jeszcze bardziej złożony zestaw zasad rzutowania. Obawiam się, że dodanie niepodpisanych ints jeszcze bardziej zdezorientuje nas wszystkich.

Zachowam tę sugestię w książkach. Ale spośród wszystkich funkcji, które moglibyśmy / powinniśmy dodać, ta z szacunkiem nie znajduje się na szczycie tej listy.

Źródło: Microsoft Connect

Chciałbym znacznie dodać do listy pro i powtórzyć, że ich silnik SQL robi FAR bardziej złożone rzeczy niż to, a więc ich zespół może poradzić sobie z dodatkową złożonością. Chociaż nie zgadzam się z ich podsumowaniem, to dlatego SQL Server nie obsługuje typów niepodpisanych .

Link Connect został pierwotnie opublikowany przez Martina Smitha w komentarzach do pytania.

— Ehryk
źródło

„mylić nas jeszcze bardziej” - prawdopodobnie odnosi się do wszystkich osób korzystających z SQL Server, a nie tylko własnego zespołu programistów.

— Oskar Berggren