Por que os tipos inteiros não assinados não estão disponíveis nas principais plataformas de banco de dados?

Os bancos de dados geralmente são muito personalizáveis, com diferentes tipos de dados e comprimentos personalizados.

Isso me surpreende, pois tento procurar a sintaxe para usar unsigned inttipos que não estão disponíveis no PostgreSQL e no MS SQL Server. MySQL e Oracle parecem.

Isso parece uma omissão flagrante da parte deles - a próxima melhor opção de perfomant é uma long / bigint (número inteiro de 8 bytes), mas pode ser completamente desnecessária! Alguém sabe por que eles escolheriam não incluir suporte int nativo não assinado?

sql-server postgresql datatypes

— Ehryk
fonte

Portátil == padrão exigido. O padrão C não especifica a largura das entradas ou dos comprimentos comuns, apenas faixas mínimas de números representáveis. Plataformas com entradas de 16 bits eram comuns em algum momento. 64 bits é possível. 36 também (embora extinto). 24 acontece (DSPs). Quantas vezes você tem dados que se encaixam em 32 bits, mas não 31, e mediu que o uso de tipos numéricos comuns gera um impacto no desempenho?

— Mat

Ambos SQL-Server e Postgres tem NUMERIC(10)que permite inteiros de até 9.999.999.999(e com uma restrição pode não permitir valores negativos.)

— ypercubeᵀᴹ

Por um motivo: eles não estão especificados no padrão SQL. Para uma mais longa discussão sobre Postgres dar uma olhada nesta discussão: postgresql.1045698.n5.nabble.com/... e isso: postgresql.1045698.n5.nabble.com/...

— a_horse_with_no_name

Para o SQL Server uma explicação é aqui

— Martin Smith

@ Mat: Não estou preocupado com o desempenho, são 4 bytes extras x 153 milhões = ~ 612 MB extras desperdiçados, os valores ultrapassam os 3 bilhões, mas não os 4 bilhões. Um numérico (10) possui resultados de desempenho além de exigir 9 bytes de armazenamento: msdn.microsoft.com/en-us/library/ms187746.aspx

— Ehryk

Jim Hogg da Microsoft respondeu a esse problema com o seguinte:

Há prós e contras. No lado profissional, parece uma boa maneira de evitar alguns erros - ter que verificar um int (assinado) tem valor> 0. E eu também arriscaria que muitos usos de int estejam de fato relacionados a contagens que nunca deveriam ser negativas de qualquer maneira . Sobre a questão de duplicar a contagem máxima de linhas? - verdade, mas eu diria que isso é menos atraente.

Do lado contrário ... misturar tipos assinados / não assinados em C ou C ++ parece que deve ser bastante simples. Não é. Ele abre um pequeno leito de erros difíceis de encontrar - principalmente devido às regras complexas para promoções / ampliações implícitas. O SQL, infelizmente, já possui um conjunto ainda mais complexo de regras de conversão implícita. Adicionar ints não assinados, temo, nos confundiria ainda mais.

Vou manter essa sugestão nos livros. Mas, dentre todos os recursos que poderíamos / deveríamos adicionar, este, com respeito, não está perto do topo dessa lista.

Fonte: Microsoft Connect

Eu acrescentaria significativamente à lista de profissionais e reiteraria que o mecanismo SQL deles já está fazendo coisas MUITO mais complexas do que isso, para que sua equipe possa lidar com a complexidade adicional. Embora eu não concorde com seu somatório, é por isso que o SQL Server não oferece suporte a tipos não assinados .

O link do Connect foi originalmente publicado por Martin Smith nos comentários da pergunta.

— Ehryk
fonte

"confunda a todos nós ainda mais" - provavelmente se refere a todos que usam o SQL Server, não apenas à sua própria equipe de desenvolvimento.

— Oskar Berggren