Pourquoi SQL Server ne prend-il pas en charge le type de données non signé?
Je pense spécifiquement à unsigned int.
Voici un exemple pratique: que faites-vous lorsque votre colonne d'identité maxes? Il est possible d'aller BigInt (stockage de 8 octets au lieu de 4) ou de refactoriser 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 n'est optimale.
UInt serait une solution idéale, mais SQL Server ne l'offre pas (où MySQL faire).
Je comprends que les types de données non signés ne font pas partie du standard SQL (SQL-2003) mais me semble toujours un gaspillage.
Quelle est la raison de ne pas les inclure (dans SQL Server ou dans la norme)?
3 réponses
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é peut faire qu'un entier signé ne peut pas faire. En ce qui concerne le cas où vous avez besoin d'un nombre entre 2147483648 et 4294967296, vous devriez probablement aller à un entier de 8 octets puisque le nombre finira également par dépasser 4294967296.
À cette fin, vous pouvez utiliser -2 147 483 648 comme valeur de départ.
Identity(-2147483648, 1)
J'ai trouvé une question similaire sur Microsoft Connect.
La réponse de Jim Hogg (Gestionnaire de programme) a des pro et des con pour ajouter des int non signés. le principal inconvénient est que les règles pour implémenter les conversions de type implicites deviennent un cauchemar.
La requête a été fermée comme "ne corrigera pas".