À quoi servent les clés négatives?

Un peu nouveau dans l'utilisation des bases de données SQL standard (qui travaille actuellement principalement avec MySQL), je n'ai pas encore utilisé de nombreuses utilisations de cela.

Quand et pourquoi est-il utile d'avoir des clés négatives (ou plutôt signées) pour indexer une table?

Une clé primaire est uniquement une valeur que nous avons déterminée comme étant la valeur la plus importante dans un enregistrement. Que cette clé soit un entier signé, un entier non signé, une chaîne, un blob (en fait, il y a des limites) ou un UUID (ou quel que soit le nom qu'il porte aujourd'hui), le fait est toujours que c'est une clé, et qu'elle est la chose de la plus haute importance.

Comme nous ne sommes pas contraints d'utiliser uniquement des nombres orientés positifs pour nos clés, il est logique de considérer qu'un entier signé n'atteindra que ~ 2 milliards, tandis qu'un entier non signé ira à ~ 4 milliards. Mais il n'y a rien de mal à utiliser un entier signé, en définissant la valeur initiale à ~ -2 milliards et en définissant un incrément de un. Après environ 2 milliards d'enregistrements, vous atteindrez «zéro», puis vous continuerez à environ 2 milliards.

Quant à savoir pourquoi il serait utile d'avoir des "clés négatives" dans une table, c'est la même question que "pourquoi est-il utile d'avoir des clés dans une table". La "valeur" d'une clé n'a aucun impact sur son statut de clé. Une clé est une clé est une clé.

Ce qui est important, c'est si la clé est valide.

Quant à savoir pourquoi il serait utile d'autoriser les clés négatives, je peux suggérer quelques raisons:

Et si vous vouliez indiquer les retours dans un système de vente sous forme de numéros de commande client négatifs, qui correspondaient au numéro de commande client positif, facilitant ainsi la corrélation (c'est naïf et mal conçu, mais cela fonctionnerait dans un sens de «feuille de calcul»).

Et si vous vouliez avoir une table d'utilisateurs et indiquer que ceux avec des nombres négatifs étaient contrôlés par le système (SO fait cela, pour les utilisateurs du fil de discussion).

Je pourrais continuer, mais vraiment la seule raison pour laquelle le nombre étant négatif est important si vous ou moi lui attribuons de l'importance. En dehors de cela, il n'y a pas de grande raison pour que la valeur d'une clé ait une incidence sur la clé elle-même.

Si nous parlons de colonnes d'identité ou de numérotation automatique, la valeur elle-même ne devrait pas avoir de sens. (parfois c'est le cas, selon les utilisateurs de chat de SO mentionnés par drachenstern, ce que j'ai fait avant moi-même)

Cependant, vous perdriez généralement la moitié de votre plage si vous utilisez des entiers signés.
Voir: Que faire lorsqu'un champ dans une table approche de l'entier 32 bits signé ou non signé max?

Autre exemple: dans les petits scénarios de réplication, l'utilisation de valeurs négatives pour un site et positives pour un autre donne une connaissance implicite de la source d'une ligne donnée.

Tous les systèmes de base de données ne prennent même pas en charge les types entiers non signés, MSSQL étant l'un de ceux qui ne le font pas. Dans ces cas, des valeurs négatives sont possibles dans les champs de clé entière simplement parce qu'elles sont possibles dans le type (vous pouvez utiliser des règles ou des déclencheurs pour les bloquer, comme indiqué dans cet exemple , mais il n'est probablement pas nécessaire d'ajouter la surcharge d'application de ces règles à chaque intersection / mise à jour).

En ce qui concerne la base de données, la valeur réelle d'une clé primaire n'a pas d'importance tant qu'elle est unique dans la table. Pour lui -42 et 42 ne sont que deux nombres différents de la même manière que 42 et 69 - le sens ne sera communiqué que sur la négativité ou non de la valeur par votre code.

Ne pas prendre en charge les types entiers non signés est probablement une décision de conception basée sur la réduction de la complexité - c'est-à-dire ne pas vouloir que deux types entiers 32 bits différents se soucient de vérifier les plages lors de l'affectation de valeurs entre eux. Cela limite le nombre d'index possibles dans un champ d'incrémentation automatique commençant un 0 ou 1 à la moitié de ce qui serait possible dans un type non signé (~ 2e9 plutôt que ~ 4e9) mais c'est rarement un problème important (si vous êtes susceptible d'avoir besoin un certain nombre de valeurs clés de cette ampleur, vous avez probablement opté pour un type 64 bits de toute façon, surtout si vous utilisez une architecture 64 bits où ces valeurs sont traitées non moins efficacement que celles de 32 bits), mais si vous souhaitez la plage complète et le besoin pour s'en tenir à 32 bits pour des raisons d'espace, vous pouvez commencer l'incrément à -2.147.483.647.