Pourquoi SQL Server ne prend-il pas en charge le type de données non signé?

Question

Je pense notamment unsigned int.

Voici un exemple pratique: que faites-vous lorsque votre colonne d'identité maxes? Il est possible d'aller BigInt (8 octets de stockage au lieu de 4) ou de revoir l'application pour prendre en charge les entiers négatifs, et même de créer vos propres règles, comme indiqué dans cette réponse; aucune de ces options sont tout à fait optimales.

UInt serait une solution idéale, mais SQL Server n'offre pas (lorsque MySQL n').

Je comprends que unsigned les types de données ne font pas partie de la norme SQL (SQL-2003), mais semble encore comme un déchets vers moi.

Quelle est la raison de ne pas inclure ces (dans SQL Server ou dans la norme)?

Answer 1

Si je devais deviner, je dirais qu'ils essaient d'éviter une prolifération de types. D'une manière générale, il n'y a rien qu'un entier non signé puisse faire qu'un entier signé ne puisse pas faire. En ce qui concerne le cas où vous avez besoin d'un nombre compris entre 2147483648 et 4294967296, vous devriez probablement passer à un entier de 8 octets car le nombre dépassera également éventuellement 4294967296.

Answer 2

À cette fin, vous pouvez utiliser -2 147 483 648 comme valeur de départ.

 Identity(-2147483648, 1)
 

Answer 3

J'ai trouvé une question similaire sur Microsoft Connect.
La réponse de Jim Hogg (gestionnaire de programme) a quelques avantages et inconvénients pour ajouter des int non signés. Le principal inconvénient est que les règles pour implémenter les conversions de types implicites deviennent un cauchemar pour aller de l'avant.