Perché i tipi interi senza segno sono disponibili nelle principali piattaforme di database?

I database sono generalmente molto personalizzabili con diversi tipi di dati e lunghezze personalizzate.

Mi sorprende, mentre provo a cercare la sintassi per usare unsigned inttipi che non sono disponibili da PostgreSQL e MS SQL Server. Sembra che MySQL e Oracle.

Sembra un'omissione lampante da parte loro - la migliore opzione successiva è un long / bigint, (intero di 8 byte), ma potrebbe essere del tutto inutile! Qualcuno sa perché dovrebbero scegliere di non includere il supporto int nativo senza segno?

sql-server postgresql datatypes

— Ehryk
fonte

Portatile == standard obbligatorio. Lo standard C non specifica la larghezza di interi o long ordinari, ma solo intervalli minimi di numeri rappresentabili. Le piattaforme con 16 bit ints erano comuni ad un certo punto. 64 bit è possibile. Anche 36 (anche se estinto). 24 succede (DSP). Quante volte hai dati che si adattano a 32 bit ma non a 31 e che hai misurato che l'uso di tipi numerici ordinari ti dà un successo?

— Mat

Sia SQL-Server che Postgres ha NUMERIC(10)che consente numeri interi fino a 9.999.999.999(e con un vincolo è possibile non consentire valori negativi.)

— ypercubeᵀᴹ

Per un motivo: non sono specificati nello standard SQL. Per una discussione più lunga su Postgres dai un'occhiata a questa discussione: postgresql.1045698.n5.nabble.com/… e questo: postgresql.1045698.n5.nabble.com/…

— a_horse_with_no_name

Per SQL Server è disponibile una spiegazione

— Martin Smith,

@Mat Non sono il problema delle prestazioni di cui sono preoccupato, sono 4 byte extra x 153 milioni = ~ 612 MB in più sprecati, i valori superano i 3 miliardi ma non i 4 miliardi. A numerica (10) presenta risultati performace oltre a richiedere 9 byte di memoria: msdn.microsoft.com/en-us/library/ms187746.aspx

— Ehryk

Jim Hogg di Microsoft ha risposto a questo problema con quanto segue:

Ci sono pro e contro. Dal punto di vista professionale, sembra un buon modo per evitare alcuni errori: dover verificare che un int (firmato) abbia un valore> 0. E vorrei anche avventurarmi sul fatto che molti usi di int si riferiscano a conteggi che non dovrebbero mai essere negativi comunque . Sulla domanda di raddoppiare il numero massimo di righe? - vero, ma direi che è meno convincente.

Per contro ... mescolare tipi firmati / non firmati in C o C ++ sembra che dovrebbe essere abbastanza semplice. Non è. Apre una piccola serie di errori difficili da trovare, principalmente a causa delle complesse regole per promozioni / ampliamenti impliciti. SQL, purtroppo, ha già un insieme ancora più complesso di regole di cast implicite. L'aggiunta di integri non firmati, temo, ci confonderebbe ancora di più.

Terrò questo suggerimento sui libri. Ma, tra tutte le funzionalità che potremmo / dovremmo aggiungere, questa, per quanto riguarda, non è vicino alla cima di quell'elenco.

Fonte: Microsoft Connect

Vorrei aggiungere in modo significativo all'elenco dei professionisti e ribadire che il loro motore SQL sta già facendo cose molto più complesse di così, e quindi il loro team può gestire la complessità aggiunta. Anche se non sono d'accordo con la loro somma, ecco perché SQL Server non supporta tipi senza segno .

Il collegamento Connect è stato originariamente pubblicato da Martin Smith nei commenti alla domanda.

— Ehryk
fonte

"confondici ancora di più" - probabilmente si riferisce a tutti coloro che utilizzano SQL Server, non solo al proprio team di sviluppo.

— Oskar Berggren,