Aggiungi un ID in ogni tabella anche se non è necessario?

In molti casi, avere un ID artificiale su ogni tavolo è molto conveniente; in alcuni casi, è solo un dolore in a **.

Generalmente, lo faccio su ogni progetto su cui sto lavorando.

I vantaggi:

• Generalmente è più facile scrivere o generare un codice di accesso quando è possibile accedere a ciascuna tabella mediante un campo chiave chiamato ID , digitare Integer .

• A volte le chiavi naturali sono volatili. Ad esempio, in un sistema di gestione magazzino già molto complesso, ci siamo trovati di fronte all'attività che i codici prodotto cambiano, ad es. quello che è stato il prodotto 001234 sarà conosciuto come 002345 in futuro. Sfortunatamente, quel sistema non usava ID artificiali, ma il codice prodotto come chiave primaria. Naturalmente, il codice prodotto era anche una chiave estranea in dozzine di altri tavoli. Pertanto, la rinumerazione era davvero difficile e costosa e non poteva essere eseguita durante l'orario di lavoro. La prossima versione del software utilizzava ID artificiali, quindi era solo un semplice UPDATE sulla tabella dei prodotti.

• A volte le chiavi naturali non sono uniche anche se dovrebbero essere. Nei miei paesi, per alcuni motivi, alcuni SSN sono stati emessi due volte.

• I tasti concentranti diventano ingombranti quando la struttura dei dati è complessa; avere un sotto-sotto-sotto-tavolo con una chiave concatenata di 4 parti è piuttosto doloroso con cui lavorare.

Svantaggi:

• Per loro natura, quegli ID non hanno significato al di fuori del sistema, quindi hai bisogno di molte ricerche per tradurre quegli ID in chiavi naturali.

• Ottenere la chiave in alto da detta sotto-sotto-sotto-tabella richiede un grosso join attraverso l'intera gerarchia.

• L'unione dei dati in arrivo con i record esistenti è più difficile, perché sono necessarie ancora più ricerche.

tasti sintetici vs tasti naturali e tasti singoli contro tasti composti sono argomenti molto dibattuti che hanno buoni lati positivi e negativi su entrambi i lati. Sono come le schede vs spazi e parentesi graffe sui loro dibattiti di linea.

La cosa più importante è scegliere un lato e mantenerlo coerente per tutto il database. i tasti generalmente sintetici sono usati semplicemente perché è difficile avere una buona chiave naturale per ogni tabella ed è molto più facile essere coerenti quando ogni tabella ha una chiave sintetica.

Ogni tabella dovrebbe avere un PK, un identificatore univoco o ID come lo chiami. Nel caso di MxN hai PK, (un Compound). Quindi non c'è bisogno di avere un altro.

Vedi anche: Uno o due tasti primari nella tabella many-to-many ?

La mia preferenza personale relativa a un argomento correlato: i PK non dovrebbero avere un altro uso oltre a essere un PK. Quindi non utilizzerei i dati a un PK, anche se i dati sono "Naturalmente unici" IE: SSN, Data, Codice postale Ect.

Dal punto di vista del design, vai con la chiave primaria composta naturale e non inventarne una sintetica. Tutto ciò che non deve essere lì rende solo lo schema più complicato da capire.

Dal punto di vista delle prestazioni in molti database è più veloce accedere alla tabella con la chiave primaria intera che con qualsiasi altra colonna indicizzata. Questi database aggiungeranno implicitamente tale chiave sintetica a qualsiasi tabella che non ne ha uno (di solito chiamato "rowid" o "oid" o simile), quindi aggiungerlo in modo esplicito non costerà nulla.

Per le tabelle MxN (relazioni) non ha senso accedervi tramite la chiave primaria; puoi accedervi da entrambi i componenti e ottenere il set di entità correlate dall'altra parte. Quindi per queste tabelle non ha senso aggiungere una chiave primaria sintetica.

Per le altre tabelle con una buona chiave primaria composta o non intera, non aggiungerei ancora quella sintetica inizialmente, ma prenderei in considerazione l'aggiunta durante la regolazione delle prestazioni per le tabelle a cui si accede in tabelle con prestazioni critiche.