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 à utiliser unsigned int types qu'ils 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é?
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 donc gérer la complexité supplémentaire. Bien que je ne sois pas d'accord avec leur résumé, 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.