Condividere una singola sequenza di chiavi primarie su un database?

È una pratica accettabile usare una singola sequenza come chiave primaria su tutte le tabelle (invece che una chiave primaria sia unica per una determinata tabella, è unica per tutte le tabelle)? In tal caso, è oggettivamente meglio dell'utilizzo di una singola sequenza di chiavi primarie tra le tabelle.

Sono uno sviluppatore di software junior, non un DBA, quindi sto ancora imparando molte delle basi di una buona progettazione di database.

Modifica: Nel caso qualcuno si stia chiedendo, di recente ho letto una critica alla progettazione di un database da parte di uno dei DBA della nostra azienda che ha menzionato il fatto che il design non ha utilizzato una singola chiave primaria nell'intero database, che suonava in modo diverso rispetto a quello Ho imparato finora.

Edit2: per rispondere a una domanda nei commenti, questo è per Oracle 11g, ma mi chiedevo a un livello specifico non di database. Se questa domanda dipende dal database, sarei interessato a sapere perché, ma in tal caso cercherò una risposta specifica per Oracle.

Accettabile? Sicuro. Comune? No. Benefico? Dubbioso.

Nel mio vecchio lavoro abbiamo ereditato un sistema in cui avevano un generatore di sequenza centrale (questo era un sistema SQL Server molto prima che SEQUENCEfosse introdotto in SQL Server 2012). Non è stato davvero un collo di bottiglia nelle prestazioni e non dovrebbe esserlo a meno che non si generino centinaia di migliaia di valori al secondo. Ma ha reso tutto il codice molto più complesso di quanto doveva essere, senza una buona ragione. L'intento del progetto era quello di essere sicuri che se a qualcosa nel sistema fosse assegnato un valore ID di 12, solo una cosa nel sistema poteva avere l'ID 12. Questo mi sembrava abbastanza ottuso e non l'ho mai capito. Se ho un cliente con CustomerID = 12, perché ciò mi impedisce di avere un ordine con OrderID = 12?

Vedo l'utilità di un generatore di sequenza centrale se hai più sistemi e stai generando ID per un certo tipo di entità (ad esempio, un cliente o un ordine) da questi sistemi multipli. Una sequenza centrale può distribuire nuovi valori a più sistemi senza essere un collo di bottiglia (solo un singolo punto di errore) e senza timore che due sistemi generino lo stesso ID.

L'idea ha il merito in un database molto complesso in cui le persone potrebbero accidentalmente unirsi a una tabella usando la colonna sbagliata e ottenere righe non valide solo perché gli ID INT sono gli stessi.

Abbiamo scelto di avere GUID sequenziali come chiavi primarie per evitare alcune trappole della frammentazione dell'Indice dei GUID. Purtroppo sono abbastanza grandi.

Il server SQL può generare GUID sequenziali tramite un valore predefinito che richiama la funzione newSequentialID (), quindi non esiste alcuna tabella di chiavi emesse da mantenere e nessun collo di bottiglia di blocco.

Questo ci ha fornito ID univoci in tutti i database, in tutta la nostra azienda, in quanto sono davvero unici.

Il prezzo ovviamente è lo spazio ed è problematico quando si tenta di trasferire i dati a un data warehouse / cubo in cui la velocità / le dimensioni sono basate sull'uso di chiavi intere più piccole.

Sono convinto che abbiamo evitato molti bug nella nostra app come risultato del loro utilizzo.

Non riesco a immaginare quale potrebbe essere la ragione dietro la singola sequenza su tutte le tabelle. Tutto ciò che fa è creare un collo di bottiglia durante la generazione di nuovi valori.

Non importa quanto sia piccolo il sovraccarico di generare valori chiave sequenziali, il generatore è una singola risorsa, il cui accesso deve essere sincronizzato. Più richieste riceve, maggiori sono le possibilità che alcuni richiedenti debbano attendere il loro turno al rubinetto. È ovvio che al singolo generatore di sequenza condiviso tra tutte le tabelle sarà possibile accedere più frequentemente da più client, producendo così più contese rispetto a uno qualsiasi dei generatori multipli. La contesa può diventare più pronunciata se le regole aziendali impongono vincoli ai valori generati, come l'assenza di lacune o ordini rigorosi, o in un database cluster.

Anche con il generatore di sequenze più efficiente ci sarà un carico di lavoro che provoca contese non tollerabili.

lo scopo di PrimaryKey nelle tabelle del database è principalmente quello di imporre l'unicità dei dati che si presume essere univoci, poiché non è possibile coprire tutti i flussi di lavoro e assicurarsi che non comporti la duplicazione dei dati. Il secondo motivo è che molte volte PK è anche il candidato principale per l'indice cluster sulla tabella, quindi aumenta anche il recupero dei dati quando / dove queste colonne sono usate correttamente nella query selezionata.

l'utilizzo di un numero progressivo come chiave primaria è lo stesso di ogni tabella con colonna Identità e solo quella colonna viene utilizzata in PrimaryKey. avere un singolo numero di sequenza nel DB deve avere un uso specifico ma dal punto di vista di PrimaryKey non capisco il motivo. ad esempio in uno dei progetti Datawarehouse a cui ho lavorato, abbiamo Column chiamato LoadBatchID e da ETL a riportare il 50% di tutta la tabella ha questa colonna ma in alcuni punti ha un significato diverso. abbiamo utilizzato l'esclusivo proc come generatore di numeri per assicurarci di non trovare conflitti e anche di aiutarci a risalire al file originale da dove provengono i dati e cosa succede in ogni diversa fase di ETL.

Suppongo che una ragione per farlo sarebbe se tutte le entità ereditate da qualche entità madre. Supponiamo, ad esempio, che tu possa essere in grado di inserire un commento su qualsiasi tipo di entità:

create table god_entity (
  id bigserial primary key
);

create table some_table (
  id bigint primary key references god_entity(id),
  ...
);

create table some_other_table (
  id bigint primary key references god_entity(id),
  ...
);

create table comment (
  id bigint primary key references god_entity(id),
  ...
);

create table entity_comment (
  entity_id bigint not null references god_entity(id),
  comment_id bigint not null references god_entity(id),

  primary key (entity_id, comment_id)
);

Di solito questo non è fatto. .

Non conosco le caratteristiche prestazionali.