A cosa servono i tasti negativi?


12

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?


5
prima di tutto, chi effettua il downvoting senza lasciare feedback, sta facendo un disservizio. Successivamente, la risposta a questa eccellente domanda.
jcolebrand

1
Questo argomento è intrigante. Personalmente non ho mai sentito parlare di questo concetto. Questa domanda non avrebbe mai dovuto essere soggetta a downgrade +1 da parte mia per aver introdotto questo concetto.
RolandoMySQLDBA

Risposte:


13

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.


Modificato il bit di "occorrenza di nicchia", poiché è probabilmente un malinteso a causa dell'inesperienza. Lettura interessante. In qualche modo immaginavo che ci sarebbe una situazione in cui il valore negativo della chiave fosse in qualche modo utile nella codifica (i, e senza decidere che significhi una cosa particolare) ma questo è molto utile pensare quando hai una forte divisione in due gruppi e non voglio usare un extra bool: p
Garet Claborn,

1
@Garet ~ Quindi fai un buon punto: "il valore della chiave è stato in qualche modo utile nella codifica" e di tanto in tanto utilizzo le mie chiavi in ​​quel modo, ma ciò non ha nulla a che fare con l'aspetto del database. Il database è un magazzino. L'applicazione che consuma i dati, d'altra parte, si preoccupa dei valori . Ma sì, quel +/- booleano è un trucco accurato, l'ho visto usato molte volte solo per un tale effetto.
jcolebrand

2
-1 per insinuare che i valori di duplice scopo come questo sono qualcosa di diverso da una cattiva idea. Hai bisogno di un int e un bool? Usa un int e un bool.
Jack dice di provare topanswers.xyz

1
@JackPDouglas Non ricordo di aver incoraggiato le persone a farlo, ricordo rigorosamente che il campo e i suoi dati sono due cose diverse. Grazie per aver almeno offerto un feedback costruttivo sul tuo downvote, ma non posso dire che quell'osservazione significhi qualcosa alla luce del concetto di "quali sono le chiavi negative utilizzate" poiché si tratta di un problema di logica dell'applicazione, non di un problema a livello di database . Volevo evidenziare come queste cose vengono utilizzate nel livello dell'applicazione, ma nel livello del database non hanno alcun significato.
jcolebrand

1
@JackPDouglas ~ Ho usato quel particolare esempio perché esiste un sito molto noto (rete di siti) di cui potresti aver sentito parlare e che fa proprio questo, quindi non voglio essere sprezzante, perché è valido "trucco". Dai un'occhiata a questo utente dba.stackexchange.com/users/-1/community e dimmi qual è il suo ID. Posso quasi assicurarti che userid è la chiave primaria (e in molte altre tabelle una chiave straniera). Solo perché è una cattiva progettazione delle applicazioni per te, non significa che non sia valida. Ma ancora una volta, questo non è design db, è design del dominio. Certo, la logica db lo supporta
jcolebrand

10

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.


e assicurati di limitare in qualche modo i valori immessi in ciascun sito, altrimenti finirai in un disastro orribile quando la tua "conoscenza implicita" risulta essere sbagliata.
Jack dice di provare topanswers.xyz

@JackPDouglas: useresti NOT FOR REPLICATION per evitare di generare valori sul sito sbagliato
gbn

insieme a vincoli di controllo ? Inoltre, c'è un analogo MySQL (o altro) NOT FOR REPLICATIONche conosci?
Jack dice di provare topanswers.xyz

@JackPDouglas: scusa, non sono sicuro di non SQL Server
gbn

8

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.


Sì, penso che abbiamo già coperto quel terreno;) tehehe dba.stackexchange.com/questions/983/…
jcolebrand

tinyint non è firmato (0 .. 255). Di solito creo un vincolo di controllo su colonne intere per garantire che i valori non siano negativi, poiché inevitabilmente verrà scritto un codice che lo presuppone implicitamente e sorgeranno strani bug se in qualche modo si insinua un valore negativo.
Ed Avis
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.