Para que são usadas as chaves negativas?

Um pouco novo no uso de bancos de dados SQL padrão (atualmente trabalhando principalmente com o MySQL) ainda não encontrei muitos usos disso.

Quando e por que é útil ter chaves negativas (ou melhor, assinadas) indexando uma tabela?

Tudo o que uma chave primária é é um valor que determinamos ser o de maior importância em um registro. Se essa chave é um int assinado, um não assinado, uma string, um blob (na verdade, existem limites) ou um UUID (ou qualquer que seja o nome que leva hoje), o fato ainda é que é uma chave e que é a coisa da maior importância.

Como não somos constrangidos a usar apenas números orientados positivos para nossas chaves, faz sentido considerar que um int assinado irá apenas para ~ 2 bilhões, enquanto um int não assinado irá para ~ 4 bilhões. Mas não há nada de errado em usar um int assinado, configurando o valor inicial para ~ -2 bilhões e configurando um incremento de um. Após ~ 2 bilhões de registros, você atingirá "zero" e continuará a ~ 2 bilhões.

Quanto ao motivo pelo qual seria útil ter "chaves negativas" em uma tabela, essa é a mesma pergunta que "por que é útil ter chaves em uma tabela". O "valor" de uma chave não afeta seu status como chave. Uma chave é uma chave é uma chave.

O importante é se a chave é válida.

Quanto ao motivo pelo qual seria útil permitir chaves negativas, posso sugerir alguns motivos:

E se você quisesse indicar retornos em um sistema de vendas como números negativos de pedidos de vendas, que correspondessem ao número positivo de pedidos de vendas, facilitando a correlação (isso é ingênuo e mal projetado, mas funcionaria no sentido de "planilha").

E se você quiser ter uma tabela de usuários e indicar que aqueles com números negativos foram controlados pelo sistema (o SO faz exatamente isso para usuários de feed de bate-papo).

Eu poderia continuar, mas realmente a única razão pela qual o número negativo é importante é se você ou eu atribuímos importância a ele. Além disso, não há uma grande razão para o valor de uma chave ter alguma influência na própria chave.

Se falamos sobre colunas de identidade ou número automático, o valor em si não deve ter significado. (às vezes acontece, de acordo com os usuários de bate-papo da SO mencionados pelo drachenstern, o que eu fiz antes de mim)

No entanto, geralmente você perderia metade do seu intervalo se estiver usando números inteiros assinados.
Consulte: O que fazer quando um campo em uma tabela se aproxima do número inteiro máximo de 32 bits com ou sem sinal?

Outro exemplo: em pequenos cenários de replicação, o uso de valores negativos para um site e positivos para outro fornece algum conhecimento implícito da origem de qualquer linha.

Nem todos os sistemas de banco de dados oferecem suporte a tipos inteiros não assinados, sendo o MSSQL um deles. Nesses casos, valores negativos são possíveis nos campos de chave inteira simplesmente porque são possíveis no tipo (você pode usar regras ou gatilhos para bloqueá-los, conforme mostrado neste exemplo , mas provavelmente não há necessidade de adicionar a sobrecarga de impor tais regras a cada inters / atualização).

No que diz respeito ao banco de dados, o valor real de uma chave primária não importa, desde que seja exclusivo na tabela. Para ele, -42 e 42 são apenas dois números diferentes, da mesma forma que 42 e 69 são - o significado só será dado à negatividade ou não do valor pelo seu código.

Não oferecer suporte a tipos inteiros não assinados é provavelmente uma decisão de design baseada na redução da complexidade - ou seja, não desejar que dois tipos inteiros de 32 bits se preocupem com a verificação de intervalos ao atribuir valores entre eles. Ele limita o número de índices possíveis em um campo de incremento automático iniciando de 0 ou 1 à metade do que seria possível em um tipo não assinado (~ 2e9 em vez de ~ 4e9), mas isso raramente é um problema significativo (se é provável que você precise vários valores-chave dessa magnitude, você provavelmente optou por um tipo de 64 bits, especialmente se estiver usando uma arquitetura de 64 bits em que esses valores são processados ​​com menos eficiência do que os de 32 bits), se você quiser a gama completa e a necessidade para manter 32 bits por motivos de espaço, você pode iniciar o incremento em -2.147.483.647.