Colonne di identità o UDF che genera in modo esplicito un ID univoco?

Question

Sono nel bel mezzo di un dibattito se sia meglio fare un PRIMARY KEY fuori da un colonne identity , il nostro da un'UDF che genera in modo esplicito un unico id.

• io sostengo per la colonna Identity.
• Il mio compagno sta discutendo per generare i valori manualmente, egli sostiene
  • mettendo l'UDF su un altro tavolo dove possiamo avere un UDF
    • bloccare la risorsa
    • incrementare una tabella ID con un campo chiamato ID_Value da 1
    • utilizzare questo come un identificatore univoco globale
  • o hanno la tabella di fare un id+1 quando si inserisce
  • Questo è più semplice per spostare i dati tra i server e / o ambienti che non hanno il vincolo identificare; si spostano da un DB dove c'è dati ad un altro DB simile con messa in scena lascia dire o dati fittizi. Per testare in non produzione potremmo voler estrarre tutti i record di ieri fino a mettere in scena per il test.

Quale implementazione ha più senso?

Answer 1

Il vostro collega è un idiota.

La soluzione non sarà scalabile, l'UDF non è concomitante ( stessa ragione di questo ). E come si fa a trattare con inserti multi-righe: ciò richiederebbe una chiamata UDF per riga

E migrazione verso altri RDBMS non capita spesso nella vita reale ... si può anche non utilizzare SQL Server ora e sull'uso di sequenze su Oracle e spero che non migrano via.

Modifica:

I tuoi aggiornamento afferma che lo spostamento dei dati è per l'aggiornamento dei database non di produzione.

In questo caso, si ignora il colonne di identità durante l'aggiornamento. Non compromettere l'implementazione per rendere non-prod carico più facile. O le tabelle del temp uso per monitorare le variazioni del valore di identità.

o processi di utilizzo: noi aggiorniamo il nostro sistema di test ogni notte dalla produzione che evita il problema del tutto. (E assicura il nostro backup prod può essere ripristinato anche)

Answer 2

Utilizzare un valore di identità. Generare i propri valori di tabella sequenza e sequenza avrà un sacco di spese generali e di causare un sacco di blocco e blocco durante il tentativo di generare numeri.

Identità esiste per un motivo, usarlo.

Quando SQL Denali esce sosterrà sequenze che sarà più efficiente di identità, ma non si può creare qualcosa di più efficiente se stessi.

Come per lo spostamento di record da un ambiente all'altro o trasformare IDENTITY_INSERT su ON quando si fa l'inserto, o controllare la casella in SSIS.

Answer 3

La colonna di identità suona bene a me. Non sono sicuro che io seguo la logica sul perché è difficile per spostare i dati tra i server.

Se si vuole ogni riga di avere un'identità unica a livello globale è possibile utilizzare un UUID, ma io non lo faresti a meno che non si è certi che l'unicità globale è necessaria - di solito non lo è. Usando UUID come IDS ridurre le prestazioni, i requisiti di spazio su disco aumentare e rendere il debug più difficile -. A causa della lunghezza, è difficile ricordare un UUID, dire a qualcuno al telefono, o scriverlo su carta senza errori

Answer 4

Per semplici ID numerici, basta andare con l'identità e dimenticare tutti i problemi della loro generazione manualmente.

È sempre possibile creare una "tavola super" che utilizza un'identità come il PK e hanno una colonna di tipo, e ogni altra informazione. Quando avete bisogno di un nuovo ID (supponendo che si intende ID univoci attraverso diverse tabelle) è sufficiente inserire in questa tabella e afferrare il SCOPE_IDENTITY() e poi inserire nella tabella effettiva è necessario.

In sostanza si crea una tabella: MasterIDs con una PK identità, quando è necessario inserire una riga nella tua Table1 INSERT INTO MasterIDs e ottenere l'identità generata da quella fila utilizzando SCOPE_IDENTITY() e quindi inserire in Tabella 1 utilizzando tale valore come il PK.

Tabella 1 avrà una non-identità int PK. Si potrebbe fare lo stesso processo da inserire nel Table2, ecc Let SQL Server gestire i valori di identità nel MasterIDs tavolo, che è quindi possibile utilizzare per le altre tabelle. MasterIDs potrebbe contenere altri tavoli, come il tipo (così si potrebbe sapere che cosa tabella, Table1 o Table2, ecc, usi che il valore di identità.

Answer 5

Fino a asyou stanno utilizzando i vincoli di chiave straniera correttamente (a cascata, aggiornamento, ecc), allora si andrà bene con l'utilizzo di un campo di identità. Io davvero non vedo un vantaggio per l'altra soluzione, in questo caso.

Answer 6

Identità è stato fatto per misura il vostro scenario. Hai strumenti come replica per Exchange Server / ambienti di dati che tengono tutto insieme.

Answer 7

Ho appena finito un pezzo di lavoro in cui ho sostituito una colonna identity SQL Server con un normale campo int e controllato allocazione Id me stesso.

ho visto abbastanza impressionanti guadagni di prestazioni. A differenza del PO, non ho una funzione definita dall'utente per generare l'id. Ma il principio è più o meno lo stesso: c'è una parte del software che gestisce un pool di id. Una volta esauriti ottiene un altro lotto interrogando il database per il prossimo Basso il valore e incrementi questo alla prossima Alta .

Questo ci permette di generare gli ID e rapportiamo tutti i soggetti al di fuori di una transazione nel nostro ORM, prima sottoponiamo i batch al database e anche sottoponiamo lotti più grandi senza andata e ritorno in più per ottenere l'identità appena inserito (richiesto da colonne di identità).

Nella tabella id abbiamo v'è più di una riga, che ci permette di utilizzare intervalli specifici, se vogliamo. vale a dire per il riutilizzo di blocchi cancellati e ID negativi.

Answer 8

Ho usato l'identità per anni e seriamente in considerazione la sostituzione numero d'identità con UNIQUEIDENTIFIER. E 'un incubo quando è necessario cambiare il tipo di dati se qualcuno ha progettato per essere un db compatto e incubo se è necessario aggiungere l'identità di una colonna, anche, non è possibile aggiornare colonna di identità. Immaginate di mettere un int e il database cresce oltre 2billion record, di nuovo incubo per il cambiamento (si pensi FKS)! Cambiare nulla con l'identità è un incubo e non si scala amichevole a meno che non si mette bigint! UNIQUEIDENTIFIER vs Identità = praticità e robustezza vs miglioramento delle prestazioni forse evidente (non ha fatto il punto di riferimento).

Aggiornamento: Dopo che ho visto questo io sicuramente magra verso UNIQUEIDENTIFIER. Questa mostra alcun beneficio reale dell'identità bigint e un mazzo di benefici per UNIQUEIDENTIFIER! Le varie versioni di SQL Server potrebbero avere un risultato diverso. C'è solo la bellezza di avere un ID univoco in tutti i database e sistemi (robustezza)! Spostare, copiare, trasformare i dati come ti pare! https://www.mssqltips.com / sqlservertip / 5105 / sql-server-prestazioni-confronto-int-versus-guid /