Pourquoi les types entiers non signés ne sont-ils pas disponibles sur les principales plateformes de base de données?

Les bases de données sont généralement très personnalisables avec différents types de données et longueurs personnalisées.

Cela m'étonne, alors que j'essaie de chercher la syntaxe pour utiliser des unsigned inttypes qui ne sont pas disponibles à partir de PostgreSQL et de MS SQL Server. MySQL et Oracle semblent le faire.

Cela semble être une omission flagrante de leur part - la prochaine meilleure option de perfomant étant un long / bigint, (entier de 8 octets), mais pourrait être complètement inutile! Quelqu'un sait-il pourquoi il choisirait de ne pas inclure le support int natif non signé?

sql-server postgresql datatypes

— Ehryk
source

Portable == standard obligatoire. La norme C ne spécifie pas la largeur des pouces ou des longs ordinaires, juste des plages minimales de nombres représentables. Les plates-formes avec des bits de 16 bits étaient courantes à un moment donné. 64 bits est possible. 36 aussi (bien qu'éteint). 24 arrive (DSP). Combien de fois avez-vous des données qui correspondent à 32 bits mais pas 31, et que vous avez mesuré que l'utilisation de types numériques ordinaires vous donne un impact sur les performances?

— Mat

SQL-Server et Postgres ont tous les deux NUMERIC(10)ce qui permet des entiers jusqu'à 9.999.999.999(et avec une contrainte, vous pouvez interdire les valeurs négatives.)

— ypercubeᵀᴹ

Pour une raison: ils ne sont pas spécifiés dans le standard SQL. Pour une discussion plus longue sur Postgres, jetez un œil à cette discussion: postgresql.1045698.n5.nabble.com/… et ceci: postgresql.1045698.n5.nabble.com/…

— a_horse_with_no_name

Pour SQL Server, une explication est ici

— Martin Smith

@Mat Ce n'est pas le problème de performance qui m'inquiète, c'est 4 octets supplémentaires x 153 millions = ~ 612 Mo supplémentaires gaspillés, les valeurs dépassent 3 milliards mais pas 4 milliards. Un numérique (10) a des hits de performance en plus de nécessiter 9 octets de stockage: msdn.microsoft.com/en-us/library/ms187746.aspx

— Ehryk

Jim Hogg de Microsoft a répondu à ce problème par les éléments suivants:

Il y a des avantages et des inconvénients. Du côté professionnel, cela semble être un bon moyen d'éviter certaines erreurs - avoir à vérifier un int (signé) a une valeur> 0. Et je me risquerais également à dire que de nombreuses utilisations de int se rapportent en fait à des décomptes qui ne devraient jamais être négatifs de toute façon . Sur la question de doubler le nombre max de lignes? - vrai, mais je dirais que c'est moins convaincant.

Du côté des inconvénients ... le mélange de types signés / non signés en C ou C ++ semble être assez simple. Ce n'est pas. Il ouvre un petit tarpit d'erreurs difficiles à trouver - la plupart en raison des règles complexes pour les promotions / élargissements implicites. Hélas, SQL dispose déjà d'un ensemble encore plus complexe de règles de transtypage implicites. Ajouter des ints non signés, je le crains, nous embrouillerait encore plus.

Je garderai cette suggestion dans les livres. Mais, parmi toutes les fonctionnalités que nous pourrions / devrions ajouter, celle-ci, avec respect, n'est pas en haut de cette liste.

Source: Microsoft Connect

J'ajouterais beaucoup à la liste des professionnels et je répéterais que leur moteur SQL fait déjà des choses beaucoup plus complexes que cela, et que leur équipe peut gérer la complexité supplémentaire. Bien que je ne sois pas d'accord avec leur sommation, c'est pourquoi SQL Server ne prend pas en charge les types non signés .

Le lien Connect a été initialement publié par Martin Smith dans les commentaires de la question.

— Ehryk
source

"nous confondre encore plus" - fait probablement référence à tous ceux qui utilisent SQL Server, pas seulement à leur propre équipe de développement.

— Oskar Berggren