¿Por qué los tipos enteros sin signo no están disponibles en las principales plataformas de bases de datos?

Las bases de datos suelen ser muy personalizables con diferentes tipos de datos y longitudes personalizadas.

Me sorprende, ya que trato de buscar la sintaxis para usar unsigned inttipos que no están disponibles en PostgreSQL y MS SQL Server. MySQL y Oracle parecen hacerlo.

Esto parece una omisión flagrante de su parte: la siguiente mejor opción de perfomante es un long / bigint (entero de 8 bytes), ¡pero podría ser completamente innecesario! ¿Alguien sabe por qué elegirían no incluir soporte int nativo sin firmar?

sql-server postgresql datatypes

— Ehryk
fuente

Portátil == estándar obligatorio. El estándar C no especifica el ancho de entradas o longitudes ordinarias, solo rangos mínimos de números representables. Las plataformas con entradas de 16 bits eran comunes en algún momento. 64bit es posible. 36 también (aunque extinto). 24 pasa (DSPs). ¿Con qué frecuencia tiene datos que se ajustan a 32 bits pero no a 31, y que ha medido que el uso de tipos numéricos comunes le da un gran rendimiento?

— Mat

Tanto SQL-Server como Postgres tienen NUMERIC(10)números enteros que permiten hasta 9.999.999.999(y con una restricción puede rechazar valores negativos.)

— ypercubeᵀᴹ

Por una razón: no se especifican en el estándar SQL. Para una discusión más larga sobre Postgres, eche un vistazo a esta discusión: postgresql.1045698.n5.nabble.com/… y esto: postgresql.1045698.n5.nabble.com/…

— a_horse_with_no_name

Para SQL Server hay una explicación aquí

— Martin Smith el

@Mat No es el impacto en el rendimiento lo que me preocupa, son 4 bytes adicionales x 153 millones = ~ 612 MB adicionales desperdiciados, los valores superan los 3 mil millones pero no los 4 mil millones. Un número (10) tiene resultados de rendimiento además de requerir 9 bytes de almacenamiento: msdn.microsoft.com/en-us/library/ms187746.aspx

— Ehryk

Jim Hogg de Microsoft ha respondido a este problema con lo siguiente:

Hay pros y contras. En el lado profesional, parece una buena manera de evitar algunos errores: tener que verificar que un int (firmado) tenga un valor> 0. Y también me aventuraría a que muchos usos de int de hecho se relacionan con conteos que nunca deberían ser negativos de todos modos . Sobre la cuestión de duplicar el recuento máximo de filas - Es cierto, pero yo diría que esto es menos convincente.

Por el lado de las desventajas ... mezclar tipos con signo / sin signo en C o C ++ parece que debería ser lo suficientemente simple. No es. Abre una pequeña tarpit de errores difíciles de encontrar, principalmente debido a las complejas reglas para promociones / ampliaciones implícitas. SQL, por desgracia, ya tiene un conjunto aún más complejo de reglas de conversión implícitas. Me temo que agregar entrantes sin firmar nos confundiría aún más.

Mantendré esta sugerencia en los libros. Pero, entre todas las características que podríamos / deberíamos agregar, esta, con respeto, no está cerca de la parte superior de esa lista.

Fuente: Microsoft Connect

Agregaría significativamente a la lista de profesionales y reiteraría que su motor SQL ya está haciendo cosas MUCHO más complejas que esto, por lo que su equipo puede manejar la complejidad adicional. Si bien no estoy de acuerdo con su resumen, esta es la razón por la cual SQL Server no admite tipos sin firmar .

El enlace Connect fue publicado originalmente por Martin Smith en los comentarios de la pregunta.

— Ehryk
fuente

"Confundirnos aún más", probablemente se refiere a todos los que usan SQL Server, no solo a su propio equipo de desarrollo.

— Oskar Berggren