Perché una chiave dovrebbe essere resa esplicita?

15

Sono molto nuovo sull'argomento dei database, quindi può sembrare ignorante, ma sono curioso di sapere perché una chiave dovrebbe essere resa esplicita all'interno di una tabella. Questo è principalmente per dire all'utente che il valore della colonna dato è (si spera) garantito per essere unico all'interno di ogni riga? L'unicità dovrebbe essere ancora presente anche se non è menzionata.

primary-key unique-constraint

— dsaxton
fonte

Vuoi dire che se hai una chiave UNICA, perché preoccuparsi di averne una PRIMARIA?

— Vérace,

1

Proprio perché sono stati dichiarati? Sembra molto utile, ma in realtà è necessario disporre di un database che funzioni?

— Dsaxton,

1

Essi non sono necessari per il database di lavoro, ma sono necessari per il vostro di dati per "lavoro", cioè essere coerenti, perché questo è esattamente come si sta dicendo il server di database per mantenere le informazioni coerenti.

— Andriy M,

Se il database sa che un determinato campo è una chiave, un effetto collaterale è che può aiutarti a localizzare la riga contenente la chiave molto più velocemente rispetto a quando deve guardare attraverso tutte le righe nelle tabelle. Gli indici sono una parte molto importante del perché i database sono utili.

— Thorbjørn Ravn Andersen,

32

Stai ovviamente suggerendo che le applicazioni CONSTRAINTdi un database dovrebbero essere applicate dalle applicazioni che / che accedono a quel database?

Ci sono molte ragioni per cui questa è una cattiva (cattiva, cattiva ...) idea.

1) Se stai costruendo un motore "vincolo" "limitato" (cioè all'interno del codice dell'applicazione), allora stai semplicemente emulando ciò che Oracle / SQL Server / MySQL / PostgreSQL / <. Chiunque ...> abbia speso anni di scrittura. Il loro codice VINCITORE è stato testato in quegli anni da milioni di utenti finali.

2) Con tutto il rispetto per te e il tuo team, non riuscirai a farlo bene anche nel giro di pochi anni - da qui il solo codice MySQL costa 40 milioni di dollari. E MySQL è il più economico dei 3 server sopra, e non implementano nemmeno CHECK CONSTRAINTs. Ovviamente, ottenere il RI (integrità referenziale) completamente giusto è difficile.

Frequentavo spesso i forum Oracle e non posso dirti quante volte un povero manager / programmatore ha avuto un progetto affidato a lui dove il genio che prima aveva il suo lavoro aveva la "brillante" idea di fare ciò che suggerisci .

Jonathan Lewis (ha scritto un libro di 550 pagine sui fondamenti dell'ottimizzatore Oracle ) dà come no. 2 dei suoi disastri di progettazione in un altro libro (" Tales of the Oak Table " - Oak Table è un gruppo di esperti Oracle) è

Verificheremo l'integrità dei dati a livello di applicazione invece di sfruttare le capacità di controllo dei vincoli di Oracle.

3) Anche se per miracolo puoi implementare correttamente il RI, dovrai reimplementarlo completamente ogni volta per ogni applicazione che tocchi quel database - e se i tuoi dati sono importanti, allora lo faranno le nuove applicazioni. Scegliere questo come paradigma porterà te e i tuoi colleghi programmatori (per non parlare del personale di supporto e delle vendite) a una vita di costante lotta antincendio e miseria.

Puoi leggere di più sul perché implementare VINCOLI di dati a livello di applicazione è assolutamente folle qui , qui e qui .

Per rispondere in modo specifico alla tua domanda:

Proprio perché sono stati dichiarati? Sembra molto utile, ma in realtà è necessario disporre di un database che funzioni

La ragione per cui KEYs (o PRIMARY, FOREIGN, UNIQUEo semplicemente ordinarie INDEXES) vengono dichiarate è che, mentre è non è strettamente necessaria per un database di provvedere alla loro funzione per esso, è assolutamente necessario per loro da dichiarare per la sua funzione di bene .

— Verace
fonte

1

Grazie per la tua risposta. Probabilmente dovrò imparare di più per capirlo appieno. (In realtà non appartengo a una squadra, sto solo imparando a conoscere i database per curiosità.)

— dsaxton

2

Leggi alcuni libri (Date, Garcia-Molina ...) e torna da noi se hai domande specifiche (qui domande troppo ampie sono considerate fuori tema). ps Benvenuti nel forum :-)

— Vérace il

Mentre non avrei mai, mai suggerire che si mette nessun vincoli nel database (Si dovrebbe sempre avere una chiave primaria e chiavi esterne ad un minimo), si potrebbe evitare 3 # per avere tutte le applicazioni consumano da un servizio condiviso (Service Oriented Architecture ). (Questo è probabilmente qualcosa che dovresti considerare per più consumatori, comunque, poiché fare ogni ultimo controllo di integrità di cui hai bisogno nel database può diventare anche da incubo. Pensa che inneschi ovunque effettuando controlli su tabelle e righe in ogni momento.)

— jpmc26

10

Quando si crea una chiave in un database, il motore DBMS applica un vincolo di unicità sugli attributi della chiave. Questo serve almeno tre scopi correlati:

Integrità dei dati: non è possibile inserire dati duplicati negli attributi chiave. Sono pertanto garantite eventuali dipendenze dalle chiavi.
Identificazione: gli utenti possono fare affidamento sulle chiavi come mezzo per identificare e aggiornare i dati con precisione.
Ottimizzazione: le informazioni (metadati) su quali attributi sono univoci sono disponibili per l'ottimizzatore di query DBMS. Queste informazioni consentono all'ottimizzatore di semplificare l'esecuzione delle query in determinati modi in modo che le query vengano eseguite più rapidamente.

— nvogel
fonte

8

Aggiungerò un aspetto alle risposte eccellenti esistenti: documentazione. Spesso è importante vedere quali tipi di chiavi è possibile utilizzare per identificare un'entità. Qualsiasi combinazione di colonne univoche è una chiave candidata.

La chiave primaria tende ad essere un concetto particolarmente utile in pratica.

Indipendentemente dal fatto che tu imponga o meno una chiave (probabilmente dovresti) la documentazione è preziosa a sé stante.

— boot4life
fonte

1

Diagrammi di database! La prima cosa che faccio sempre quando mi viene chiesto di dire qualcosa di significativo sul software che non ho familiarità è vedere se utilizza un database relazionale e, in caso affermativo, provare a creare un diagramma del database. Questo mi darà un'idea eccellente delle informazioni con cui l'applicazione funziona. Sfortunatamente, il 90% dei database che ho visto non dichiara chiavi esterne, quindi i diagrammi sono solo insiemi di tabelle. La deduzione di chiavi esterne implicite a livello di applicazione richiede congetture e modifiche.

— reinierpost,

1

@reinierpost Sono pienamente d'accordo. I dati sono l'oggetto più prezioso da documentare e da mantenere pulito perché persiste per sempre. Il codice può cambiare; tende ad essere più transitorio.

— boot4life,

@reinierpost - Consultato per una società che ha fornito software per l' intera infrastruttura ferroviaria di un grande paese europeo (grande - pensa miliardi di widget) e ho detto: "Hum, eseguirò una query per verificare le FOREIGN KEYdefinizioni per ottenere un cercare il sistema ". La mia richiesta ha restituito zip !!! Certo che il mio SQL doveva essere sbagliato, l'ho menzionato a uno dei programmatori senior. Con orgoglio (non meno) annunciò (come se stesse presentando un figlio appena nato) che il sistema non aveva alcun FK perché "tutte le ricerche sono su PRIMARY KEYs" - (irrilevante). <Doh ...> a la Homer Simpson!

— Vérace,

5

Un altro motivo per cui dovresti usare CONSTRAINT al posto di alcuni codici all'interno dell'applicazione:

Cosa succede se uno sviluppatore / dba utilizza un'istruzione insert / update / delete per modificare i dati direttamente nel DB? In questo caso tutta l'integrità referenziale basata sulla tua bella applicazione sarà inutile. Lo so, ad alcuni sviluppatori piace la possibilità di modificare i dati direttamente senza doversi preoccupare del RI perché sanno cosa fanno - almeno il più delle volte (ma non sempre)

PS: Certo che potresti creare trigger, ma di solito sono terribilmente lenti (rispetto ai VINCOLI).

— Thomas Franz
fonte