Pro e contro di applicazione della chiave esterna a livello di programmazione rispetto al database

Question

Ciò causa così tanti problemi in termini di sviluppo semplicemente lasciando che il database imponga la chiave esterna. Soprattutto durante il test unitario non posso rilasciare la tabella a causa di vincoli di chiave esterna, ho bisogno di creare una tabella in un ordine tale che l'avviso di vincolo di chiave esterna non venga attivato. In realtà non vedo troppo il punto di lasciare che il database faccia rispettare i vincoli delle chiavi esterne. Se l'applicazione è stata progettata correttamente, non dovrebbe esserci alcuna manipolazione manuale del database oltre alle query selezionate. Voglio solo assicurarmi che non mi stia scavando in una buca non avendo vincoli di chiavi estranee nel database e lasciandolo solo alla responsabilità dell'applicazione. Mi sto perdendo qualcosa?

P.S. i miei test di unità reali (non quelli che usano il mocking) elimineranno le tabelle esistenti se la struttura dell'oggetto di dominio sottostante è stata modificata.

Answer 1

In base alla mia esperienza, se non imponi chiavi esterne in un database, alla fine (supponendo che il database sia relativamente grande e pesantemente utilizzato) si finirà con i record orfani. Questo può accadere in molti modi, ma sembra sempre che accada.

Se si indicizza correttamente, non ci dovrebbero essere vantaggi di prestazioni per le chiavi esterne.

Quindi la domanda è: il potenziale danno/problema/costo di supporto/costo finanziario di avere record orfani nel database superano i problemi di sviluppo e testing?

Nella mia esperienza, per le applicazioni aziendali uso sempre le chiavi esterne. Dovrebbe essere solo un costo di installazione una tantum per far funzionare correttamente gli script di compilazione, e la stabilità dei dati sarà più che remunerativa per tutta la durata di un'applicazione.

Answer 2

Il punto di applicazione delle regole nel database è che è dichiarativo - ad es. non devi scrivere tonnellate di codice per gestirlo.

Per quanto riguarda l'unità, è sufficiente eliminare le tabelle nell'ordine corretto. Devi solo scrivere una funzione per farlo bene una volta.

Answer 3

Ecco una bella discussione su questo in una precedente domanda su SO: What's wrong with foreign keys?. [Modifica]: L'argomento è quello di rendere le chiavi esterne non forzate per ottenere alcuni dei professionisti se uno degli aspetti negativi si applica.

Answer 4

Potrebbe sembrare che si possa fare affidamento sulle proprie applicazioni per seguire le regole implicite, ma a meno che non le si imponga, alla fine qualcuno commetterà un errore.
O forse tra 5 anni qualcuno farà un riassetto di vecchi documenti "che non sono più necessari" e non si rendono conto che ci sono dati in altre tabelle che fanno ancora riferimento a loro. Poi pochi giorni/settimane dopo tu o il tuo successore ottenete il divertente compito di provare a riparare il casino a cui il database è arrivato. :-)

Answer 5

I tuoi problemi di sviluppo non dovrebbero guidare la progettazione del DB. La ricostruzione costante di un DB è un caso di utilizzo dello sviluppatore, non un caso di utilizzo del cliente.

Inoltre, i vincoli DB aiutano oltre l'applicazione. Non sai mai cosa potrebbe tentare di fare il tuo cliente. Non farlo, ma ne hai bisogno.

Answer 6

Se l'applicazione è stata correttamente progettato non ci dovrebbe essere alcun manipolazione manuale del database altro di query di selezione

Cosa? Che tipo di Koolaid stai bevendo?La maggior parte delle applicazioni database esiste per manipolare i dati nel database e non solo per vederli. Generalmente l'intero scopo dell'applicazione è aggiungere nuovi ordini o creare nuovi record di clienti o documentare le chiamate al servizio clienti ecc.

Le chiavi esterne sono per l'integrità dei dati. L'integrità dei dati è fondamentale per poter utilizzare i dati con qualsiasi affidabilità. I database senza l'integrità dei dati sono inutili e possono far perdere denaro alle aziende. Questo trionfa sulla tua visione egocentrica che gli FK non sono necessari perché rendono lo sviluppo più complicato per te. I dati sono molto più importanti della praticità nell'esecuzione di test (che possono essere scritti per tenere conto delle FK).