È un modo standard per progettare un database?

Di recente ho appreso come vengono definite le relazioni nel database al lavoro e mi chiedevo se si tratta di una pratica standard.

Supponiamo di avere due processi: Processo A e Processo B. Il processo B dipende dai risultati del processo A, quindi esiste una relazione che deve essere definita tra un'esecuzione del processo B e un'esecuzione del processo A. Ecco come viene definita la relazione:

TableProcessA:
Id

e

TableProcessB:
Id
ProcessAId

Ora, fino a questo punto, le cose hanno un senso per me, ma poi le cose diventano un po 'strane per me e la mia comprensione del design del tavolo. Ogni volta che viene creata una riga in TableProcessA o TableProcessB, viene chiamata una funzione che crea un ID univoco globale per ciascuno. Quindi, in sostanza, tutti i campi Id in TableProcessA e TableProcessB non conterranno alcuna corrispondenza poiché gli ID non sono solo univoci per la sua tabella, ma per l'intero database.

La mia domanda è: quanto è standard? Mi è venuta l'idea che ogni tabella dovrebbe semplicemente avere un ID autoincrementante che è unico solo per la tabella e non per l'intero database.

Non è una pratica così strana. Questi sono chiamati GUID o ID globalmente univoci. L'idea è che, dato un GUID, puoi dire esattamente a quale dato appartiene l'id perché sarà unico ovunque . I GUID sono utilizzati al meglio quando si uniranno diverse fonti di dati simili; ad esempio inventario per diversi negozi.

Vorrei fare qualche ricerca e scoprire perché questa è una pratica comune nel tuo ambiente. Forse è necessario, forse no.

In linea di principio, avere ID univoci in un database non è male, ma è piuttosto insolito nella mia esperienza. A meno che non vi sia un requisito specifico per il mantenimento di chiavi ID univoche a livello globale, l'utilizzo dell'identità normale dovrebbe andare bene poiché i tipi di entità o gli oggetti tendono a essere specifici del tipo e di solito non comportano join inappropriati.

A parte la tua domanda, ti consiglio vivamente di non usare i GUID come chiavi primarie o surrogate in quanto occupano il 4x dello spazio di un int. Ora ai tempi dei dischi multi-gigabyte potresti dire che non è importante ma quando hai qualche milione di righe di dati ci vogliono ancora risorse per leggere dal disco o trasferire attraverso una rete, ancora di più se vengono inclusi in qualsiasi indice. Mentre sono sugli indici dei soggetti, i GUID sono cattivi nelle chiavi primarie a causa della loro natura casuale e di solito causa una frammentazione significativa.

Ora è probabile che sia troppo tardi per questo database, ma ricordalo per il futuro

I processi possono creare record che contengono il GUID come riferimento all'istanza del processo, ma l'utilizzo dei GUID come chiave non è necessariamente ottimale.

Vedo tre principali svantaggi dell'utilizzo dei GUID come chiavi di database e li eviterei a meno che tu non abbia qualche motivo convincente per usarli. Si noti che la proprietà unica a livello globale non offre alcun vantaggio rispetto all'utilizzo di una chiave localmente unica all'interno di una tabella, poiché si conosce già da quale tabella provengono i dati.

Inconveniente: non è terribilmente facile digitare un GUID se si desidera eseguire una query ad hoc del database, ad esempio:

select *
  from Foo
 where FooID = 12345

vs

select *
  from Foo
 where FooID = convert (uniqueidentifier, '5E64E653-35F0-4803-B459-F5F59C701F22')

Quest'ultimo praticamente significa che hai bisogno di una fonte del GUID da cui tagliare e incollare.

2. Ordinalità naturale: una chiave primaria autoincrementante ha l'effetto collaterale di ordinare naturalmente le tue transazioni nell'ordine in cui sono state inserite nel sistema. Questo è spesso abbastanza utile. I GUID non vengono normalmente generati in ordine, quindi non sono utili a questo proposito.

3. Dimensione: meno problemi in questi giorni, ma un GUID è lungo 16 byte. Occupa più spazio nella tabella e in tutti gli indici che la includono.

Non dirò che è normale, ma non è anormale nemmeno impostare le cose in questo modo.