Quando avere una colonna di identità non è una buona idea?

Question

Nelle tabelle in cui è necessaria solo una colonna come chiave, e i valori in quella colonna possono essere interi, quando non si deve utilizzare un campo identità.

Al contrario, nella stessa tabella e colonna, quando si generano manualmente i relativi valori e non si utilizzerà un valore generato automaticamente per ciascun record?

Immagino che sarebbe il caso quando ci sono molti inserimenti e cancellazioni sul tavolo. Ho ragione? Quali altre situazioni potrebbero essere?

Answer 1

Se si è già scelto il lato surrogato di Great Primary Key Debacle, non riesco a trovare un motivo per non utilizzare le chiavi di identità. Le solite alternative sono le guids (hanno molti svantaggi, principalmente di dimensione e casualità) e le chiavi generate dal livello dell'applicazione. Ma creare una chiave surrogata nel livello applicazione è un po 'più difficile di quanto sembri e inoltre non copre l'accesso ai dati non relativi alle applicazioni (ad esempio, carichi batch, importazioni, altre app, ecc.). L'unico caso speciale è rappresentato dalle applicazioni distribuite quando i guid e persino i codici sequenziali possono offrire un'alternativa migliore all'id del sito + chiavi di identità.

Answer 2

Suppongo che se si crea una tabella di collegamento molti-a-molti, in cui entrambi i campi sono foreign keys, non è necessario un campo identità.

Al giorno d'oggi immagino che la maggior parte ORMs si aspettino che ci sia un campo identità in ogni tabella. In generale, è una buona pratica fornirne uno.

Answer 3

Non è possibile (normalmente) specificare i valori durante l'inserimento in colonne di identità, così per esempio se la colonna "id" specificato come identificare il seguente SQL fallirebbe:

INSERT INTO MyTable (id, name) VALUES (1, 'Smith') 

Per eseguire questo tipo di inserire è necessario avere IDENTITY_INSERT su quella tabella - questo non è concepito per essere attivo normalmente e può essere acceso per un massimo di 1 tabelle nel database in qualsiasi momento.

Answer 4

Non sono sicuro di aver capito abbastanza del contesto, ma interpreto la domanda come:

"Se ho bisogno del database per creare una colonna univoca (per qualsiasi motivo), quando non dovrebbe essere una colonna intera (identità) monotonicamente crescente?"

In questi casi, non c'è motivo di utilizzare altro che la funzione fornita dal DBMS per lo scopo; nel tuo caso (SQL Server?) è un'identità.

eccezione:

Se avrete mai bisogno di fondere la tabella con i dati da un'altra fonte, utilizzare un GUID, che impedirà chiavi duplicate dalla collisione.

Answer 5

Se è necessario unire i database, è molto più semplice se non è necessario rigenerare le chiavi.

Answer 6

Se ho bisogno di un surrogato, vorrei utilizzare una colonna IDENTITY o una colonna GUID in base alla necessità di univocità globale.

Se esiste una chiave primaria naturale o la chiave primaria è definita come una combinazione univoca di altre chiavi esterne, in genere non ho IDENTITÀ, né la uso come chiave primaria.

Esiste un'eccezione, ovvero le tabelle di configurazione dello snapshot che sto monitorando con un trigger di controllo. In questo caso, di solito c'è una "chiave primaria" logica (solitamente la data dell'istantanea e la chiave naturale della riga - come un centro di costo o un numero di conto gl per cui la riga è un record di configurazione), ma invece di usare il naturale "chiave primaria" come chiave primaria, aggiungo un IDENTITÀ e ne faccio la chiave primaria e faccio un indice univoco o un vincolo sulla data e sulla chiave naturale. Anche se teoricamente la data e la chiave naturale non dovrebbero cambiare, in queste tabelle, se un utente lo fa invece di aggiungere una nuova riga ed eliminare la vecchia riga, voglio la verifica (che riflette una modifica a una riga identificata dalla sua chiave primaria) per riflettere davvero un cambiamento nella riga - non la scomparsa di una chiave e l'aspetto di una nuova.

Answer 7

Un caso di non volere un campo di identità sarebbe in una relazione uno a uno. La tabella secondaria avrebbe come chiave primaria lo stesso valore della tabella primaria. L'unica ragione per avere un campo di identità in quella situazione sembra essere quella di soddisfare un ORM.

Answer 8

Recentemente ho implementato un suffisso Trie in C# che potrebbe indicizzare i romanzi e quindi consentire che le ricerche vengano eseguite estremamente veloci, lineari rispetto alle dimensioni della stringa di ricerca. Una parte dei requisiti (questo era un compito a casa) era di usare la memoria offline, quindi ho usato MS SQL e avevo bisogno di una struttura per rappresentare un nodo in una tabella.

Ho finito con la seguente struttura: NodeID carattere ParentID, ecc, in cui il NodeID era una chiave primaria.

Non volevo che ciò avvenga come identità autoincrementante per due motivi principali.

1. Come si ottiene il valore di un NodeID dopo averlo aggiunto al database/tabella dati?
2. Volevo più controllo quando si trattava di generare i miei ID.