Un po 'nuovo nell'uso di database SQL standard (attualmente lavorando principalmente con MySQL). Non ho ancora incontrato molti usi di questo.
Quando e perché è utile disporre di chiavi negative (o meglio firmate) che indicizzano una tabella?
Un po 'nuovo nell'uso di database SQL standard (attualmente lavorando principalmente con MySQL). Non ho ancora incontrato molti usi di questo.
Quando e perché è utile disporre di chiavi negative (o meglio firmate) che indicizzano una tabella?
Risposte:
Tutto ciò che una chiave primaria è è un valore che abbiamo determinato è il valore che è della massima importanza in un record. Che quella chiave sia un int con segno, un int senza segno, una stringa, un BLOB (in realtà, ci sono limiti) o un UUID (o qualunque sia il nome che assume oggi), resta il fatto che è una chiave, e che lo è la cosa della massima importanza.
Dal momento che non siamo costretti a usare solo numeri con orientamento positivo per le nostre chiavi, ha senso considerare che un int firmato andrà solo a ~ 2 miliardi, mentre un int senza segno andrà a ~ 4 miliardi. Ma non c'è niente di sbagliato nell'usare un int firmato, impostando il valore iniziale su ~ -2 miliardi e impostando un incremento di uno. Dopo ~ 2 miliardi di dischi, premi "zero" e poi continuerai a ~ 2 miliardi.
Per quanto riguarda il motivo per cui sarebbe utile avere "chiavi negative" in una tabella, questa è la stessa domanda del "perché è utile avere le chiavi in una tabella". Il "valore" di una chiave non ha alcun impatto sul suo stato di chiave. Una chiave è una chiave è una chiave.
Ciò che è importante è se la chiave è valida.
Per quanto riguarda il motivo per cui sarebbe utile consentire chiavi negative, posso suggerire alcuni motivi:
E se volessi indicare i ritorni in un sistema di vendita come numeri di ordini di vendita negativi, che corrispondevano al numero di ordine di vendita positivo, rendendo così facile la correlazione (questo è ingenuo e mal progettato, ma funzionerebbe in senso "foglio di calcolo").
E se volessi avere una tabella degli utenti e indicare che quelli con numeri negativi erano controllati dal sistema (SO fa proprio questo, per gli utenti di feed di chat).
Potrei continuare, ma davvero l'unica ragione per cui il numero è negativo è importante se tu o io assegniamo importanza ad esso. A parte questo, non vi è alcuna grande ragione per cui il valore di una chiave influisca sulla chiave stessa.
Se ci occupiamo delle colonne Identity o Autonumber, il valore stesso non dovrebbe avere alcun significato. (a volte lo fa, come per gli utenti di chat di SO citati da drachenstern, cosa che ho fatto prima di me stesso)
Tuttavia, in genere perdi metà del tuo intervallo se utilizzi numeri interi con segno.
Vedi: Cosa fare quando un campo in una tabella si avvicina all'intero massimo a 32 bit con o senza segno?
Un altro esempio: in piccoli scenari di replica, l'utilizzo di valori negativi per un sito e positivo per un altro fornisce una conoscenza implicita dell'origine di una determinata riga.
NOT FOR REPLICATION
che conosci?
Non tutti i sistemi di database supportano nemmeno tipi interi senza segno, MSSQL è uno di quelli che non lo fanno. In questi casi sono possibili valori negativi nei campi chiave interi semplicemente perché sono possibili nel tipo (è possibile utilizzare regole o trigger per bloccarli, come mostrato in questo esempio , ma probabilmente non è necessario aggiungere il sovraccarico di imporre tali regole a ogni incrocio / aggiornamento).
Per quanto riguarda il database, il valore effettivo di una chiave primaria non ha importanza purché sia univoco nella tabella. Ad esso -42 e 42 sono solo due numeri diversi allo stesso modo di 42 e 69 - il significato sarà impartito solo sulla negatività o meno del valore dal tuo codice.
Non supportare i tipi di numeri interi senza segno è probabilmente una decisione di progettazione basata sulla riduzione della complessità, vale a dire che non si desidera che due diversi tipi di numeri interi a 32 bit si preoccupino di controllare gli intervalli quando si assegnano valori tra di loro. Limita il numero di indici possibili in un campo di incremento automatico iniziando da 0 o 1 alla metà di ciò che sarebbe possibile in un tipo senza segno (~ 2e9 anziché ~ 4e9) ma questo è raramente un problema significativo (se è probabile che sia necessario un certo numero di valori chiave di quella grandezza probabilmente hai optato per un tipo a 64 bit, specialmente se usi un'architettura a 64 bit in cui tali valori vengono elaborati non meno efficientemente di quelli a 32 bit) anche se potresti volere l'intero intervallo e necessità per attenersi a 32 bit per motivi di spazio è possibile avviare l'incremento a -2.147.483.647.