Devo definire le relazioni tra le tabelle nel database o solo nel codice?

Nella mia esperienza, molti dei progetti che ho letto in passato non avevano definizioni di relazioni nel database, ma li definivano solo nel codice sorgente. Quindi mi chiedo quali sono i vantaggi / gli svantaggi della definizione delle relazioni tra le tabelle nel database e nel codice sorgente? E la domanda più ampia riguarda altre funzionalità avanzate nei database moderni come cascata, trigger, procedure ... Ci sono alcuni punti nei miei pensieri:

Nel database:

• Dati corretti dalla progettazione. Prevenire errori dell'applicazione che possono causare dati non validi.

• Ridurre il round trip di rete all'applicazione quando si inseriscono / aggiornano i dati poiché l'applicazione deve eseguire più query per verificare l'integrità dei dati.

Nel codice sorgente:

• Più flessibile.

• Meglio quando si esegue il ridimensionamento su più database, poiché a volte la relazione può essere tra database.

• Maggiore controllo sull'integrità dei dati. Il database non deve controllare ogni volta che l'applicazione modifica i dati (la complessità può essere O (n) o O (n log n) (?)). Invece, è delegato all'applicazione. E penso che la gestione dell'integrità dei dati nell'applicazione porterà a messaggi di errore più dettagliati rispetto all'utilizzo del database. Ad esempio: quando si crea un server API, se si definiscono le relazioni nel database e qualcosa va storto (come se l'entità a cui si fa riferimento non esiste), si otterrà un'eccezione SQL con un messaggio. Il modo semplice sarà di restituire 500 al client che esiste un "Errore interno del server" e il client non avrà idea di cosa non vada. Oppure il server può analizzare il messaggio per capire cosa c'è che non va, che secondo me è un modo brutto e soggetto a errori. Se lasci che l'applicazione gestisca questo,

C'è niente altro?

Modifica: come sottolinea Kilian, il mio punto su prestazioni e integrità dei dati è molto fuorviante. Quindi ho modificato per correggere il mio punto lì. Capisco perfettamente che lasciare che il database lo gestisca sarà un approccio più efficiente e solido. Controlla la domanda aggiornata e riflettici.

Modifica: grazie a tutti. Le risposte che ho ricevuto sottolineano che i vincoli / le relazioni dovrebbero essere definiti nel database. :). Ho un'altra domanda, poiché è al di fuori dell'ambito di questa domanda, l'ho appena pubblicata come domanda separata: gestire l'errore del database per il server API . Si prega di lasciare alcune intuizioni.

TL; DR: i vincoli di relazione dovrebbero andare nel database.

La tua applicazione non è abbastanza grande.

Hai ragione, infatti, nel far valere le relazioni tra i database potrebbe essere necessario applicarle nell'applicazione.

Vorrei sottolineare, tuttavia, che è necessario prima verificare la documentazione del software di database che si sta utilizzando e controllare le offerte di prodotti esistenti. Ad esempio, ci sono offerte di cluster su Postgres e MySQL.

E anche se alla fine hai bisogno di avere un po 'di convalida nell'applicazione, non buttare via il bambino con l'acqua del bagno . Dopotutto, meno devi fare, meglio sei.

Infine, se sei preoccupato per i futuri problemi di scalabilità, temo che la tua applicazione dovrà subire cambiamenti significativi prima di poter comunque ridimensionare. Come regola generale, ogni volta che cresci di 10 volte, devi riprogettare ... quindi non sprechiamo troppi soldi nel non riuscire ad anticipare i problemi di scalabilità, e invece usiamo i soldi per raggiungere effettivamente il punto in cui hai quei problemi.

La tua domanda non è abbastanza corretta.

Qual è la possibilità che il database utilizzato abbia un'implementazione errata del controllo rispetto alla possibilità che l'applicazione abbia un'implementazione errata del controllo?

E quale cambi più spesso?

Scommetto che il database sia corretto, in qualsiasi momento .

I tuoi sviluppatori non stanno pensando abbastanza distribuiti.

Ridurre il round trip di rete all'applicazione quando si inseriscono / aggiornano i dati poiché l'applicazione deve eseguire più query per verificare l'integrità dei dati.

Bandiera rossa ! ¹

Se stai pensando:

• controlla se il record esiste
• in caso contrario, inserire record

quindi hai fallito il problema di base della concorrenza: un altro processo / thread potrebbe aggiungere il record mentre procedi.

Se stai pensando:

• controlla se il record esiste
• in caso contrario, inserire record
• controlla se il record è stato inserito come duplicato

quindi non sei riuscito a rendere conto di MVCC: la vista del database che hai è un'istantanea al momento dell'inizio della transazione; esso non mostra tutti gli aggiornamenti che si stanno verificando, e forse nemmeno impegnati.

Mantenere i vincoli su più sessioni è un problema davvero difficile, sii contento che sia stato risolto nel tuo database.

¹ A meno che il database non implementi correttamente la proprietà Serializable; ma pochi lo fanno davvero.

Ultimo:

E penso che gestire l'integrità dei dati nell'applicazione consentirà un messaggio di errore più dettagliato rispetto all'utilizzo del database. Ad esempio: quando si crea un server API. Se si definiscono le relazioni nel database e qualcosa va storto (come se l'entità a cui si fa riferimento non esiste), si otterrà un'eccezione SQL con messaggio.

Non analizzare i messaggi di errore , se si utilizza un database di livello produzione dovrebbe restituire errori strutturati. Avrai almeno un codice di errore per indicare ciò che è probabilmente sbagliato e in base a questo codice puoi creare un messaggio di errore adatto.

Nota che la maggior parte delle volte il codice è sufficiente: se hai un codice di errore che ti dice che non esiste una chiave esterna referenziata, è probabile che questa tabella abbia una sola chiave esterna, quindi sai nel codice qual è il problema .

Inoltre, e siamo onesti qui, la maggior parte delle volte non gestirai gli errori con garbo comunque. Solo perché ce ne sono così tanti e non riuscirai a spiegarli tutti ...

... che si lega al punto di correttezza sopra. Ogni volta che vedi un "500: Errore interno del server" perché un vincolo del database è stato attivato e non è stato gestito, significa che il database ti ha salvato, poiché hai appena dimenticato di gestirlo nel codice.

Il database non deve verificare l'integrità dei dati ogni volta che l'applicazione modifica i dati.

Questo è un punto profondamente fuorviato. I database sono stati creati proprio per questo scopo. Se hai bisogno di controlli di integrità dei dati (e se ritieni di non averne bisogno, probabilmente stai sbagliando), lasciare che il database li gestisca è quasi sicuramente più efficiente e meno soggetto ad errori rispetto a farlo nella logica dell'applicazione.

I vincoli dovrebbero risiedere nel tuo database, in quanto (con la migliore volontà al mondo), la tua applicazione non sarà l'unica cosa ad accedere a questo database.

Ad un certo punto, potrebbe essere necessario disporre di una correzione tramite script all'interno del database oppure potrebbe essere necessario migrare i dati da una tabella all'altra durante la distribuzione.

Inoltre, potresti ottenere altri requisiti, ad esempio "Il grande cliente X ha davvero bisogno di questo foglio di dati Excel importato nel nostro database delle applicazioni questo pomeriggio", dove non avrai il lusso di adattare il codice dell'applicazione per adattarlo quando uno script SQL sporco lo farà in tempo.

Qui è dove l'integrità a livello di database salverà il tuo bacon.

Inoltre, immagina lo sviluppatore che assume il tuo ruolo in questa azienda dopo che te ne sei andato e poi ha il compito di apportare modifiche al database.

Ti odierà se non ci sono vincoli FK all'interno del database in modo che possa dire quali relazioni ha una tabella prima di modificarlo? ( Indizio, la risposta è sì )

Dovresti avere delle relazioni nel database.

Come notano le altre risposte, le prestazioni del controllo dei vincoli saranno molto migliori all'interno di quel database che all'interno dell'applicazione. I controlli dei vincoli del database sono una delle cose utili per i database.

Se hai bisogno di ulteriore flessibilità, ad esempio i riferimenti incrociati del database, puoi rimuovere i vincoli deliberatamente e tenendo in considerazione. Avere coerenza all'interno del database significa avere la possibilità di modificare tali vincoli e la certezza dell'integrità referenziale.

• Non viviamo più in un back-end <-> un mondo front-end.
• La maggior parte delle soluzioni prevede un front-end Web, un front-end mobile, un front-end batch e un front-end iPad, ecc.
• I motori di database hanno già migliaia di linee testate di codice ottimizzate per imporre l'integrità referenziale.

Puoi davvero permetterti di scrivere e testare l'integrità referenziale applicando il codice quando hai un codice di risoluzione dei problemi di dominio da scrivere?

Se non convalidi l'integrità dei dati, i vincoli, le relazioni ecc. A livello di database, ciò significa che è molto più facile per chiunque abbia accesso al database di produzione (attraverso qualsiasi altro client incluso uno strumento di accesso al DB) confondere i tuoi dati.

È buona pratica applicare l'integrità dei dati più rigorosa possibile a livello di database. Fidati di me, questo ti farà risparmiare enormi mal di testa nel tempo in qualsiasi sistema non banale. Raccoglierai anche errori di logica dell'applicazione o errori e incoerenze dei requisiti aziendali più rapidamente se si pensa attentamente.

Come nota a margine, progettare il proprio database in modo quanto più normalizzato e atomico possibile. Nessun tavolo "Dio". Dedica molto impegno a progettare il tuo database in modo che sia il più semplice possibile, idealmente con molte piccole tabelle che sono individualmente molto ben definite, con una sola responsabilità e attentamente convalidate su tutte le colonne. Il database è l'ultimo custode della tua integrità dei dati. Rappresenta il mastio del castello.

La maggior parte delle persone sono essenzialmente dire "sì, in generale rendi definire sempre le relazioni nel database". Ma se le discipline dell'informatica fossero così semplici, saremmo chiamati "Lettori di manuali di software" anziché "Ingegneri di software". Sono effettivamente d'accordo sul fatto che i vincoli dovrebbero andare nel database, a meno che non ci sia una buona ragione per cui non dovrebbero , quindi lasciatemi solo fornire un paio di motivi che potrebbero essere considerati buoni in determinate situazioni:

Codice duplicato

A volte una certa quantità di funzionalità che potrebbe essere gestita dal database esisterà naturalmente nel codice dell'applicazione. Se l'aggiunta di qualcosa come i vincoli al database fosse ridondante, potrebbe essere meglio non duplicare la funzionalità, perché stai violando i principi DRY e potresti peggiorare l'atto di giocoleria di mantenere il database e il codice dell'applicazione sincronizzati.

Sforzo

Se il tuo database sta già facendo ciò che deve fare senza utilizzare funzionalità avanzate, potresti voler valutare dove dovrebbero essere collocati il ​​tuo tempo, denaro e impegno. Se l'aggiunta di vincoli impedirebbe un fallimento catastrofico e quindi risparmierebbe un sacco di soldi alla tua azienda, probabilmente ne vale la pena. Se si aggiungono vincoli che dovrebbero essere validi, ma si garantisce che non verranno mai violati, si sta perdendo tempo e si inquina la base di codice. Garantito è la parola chiave qui.

Efficienza

Questo non è normalmente un buon motivo, ma in alcuni casi potresti avere un determinato requisito di prestazioni. Se il codice dell'applicazione è in grado di implementare una determinata funzionalità in modo più rapido rispetto al database e sono necessarie prestazioni aggiuntive, potrebbe essere necessario implementare la funzionalità nel codice dell'applicazione.

Controllo

In qualche modo legato all'efficienza. A volte hai bisogno di un controllo estremamente preciso su come viene implementata una funzionalità, e talvolta se il database lo gestisce lo nasconde dietro una scatola nera che devi aprire.

Punti di chiusura

• I database sono scritti in codice. Non c'è nulla di magico che fanno e che non puoi fare nel tuo codice.
• Niente è gratis. Vincoli, relazioni, ecc. Usano tutti i cicli della CPU.
• Le persone nel mondo NoSQL vanno d'accordo senza le tradizionali funzioni relazionali. In MongoDB, ad esempio, la struttura dei documenti JSON è abbastanza buona da supportare un intero database.
• L'uso cieco e ignorante delle funzionalità avanzate del database non può garantire alcun vantaggio. Potresti accidentalmente far funzionare qualcosa solo per romperlo in seguito.
• Hai fatto una domanda molto generale senza elencare requisiti o vincoli specifici. La vera risposta alla tua domanda è "dipende".
• Non hai specificato se si trattava di un problema di scala aziendale. Altre risposte parlano di cose come i clienti e l'integrità dei dati, ma a volte queste cose non sono importanti.
• Suppongo che tu stia parlando di un tradizionale database relazionale SQL.
• La mia prospettiva viene dall'allontanarsi dall'uso di tonnellate di vincoli e chiavi esterne in progetti di piccole dimensioni (fino a 50 tavoli) e non notare alcun inconveniente .

L'ultima cosa che dirò è che saprai se non dovresti inserire la funzionalità nel database. Se non sei sicuro, probabilmente stai meglio usando le funzionalità del database, perché di solito funzionano davvero bene.

Come sempre, ci sono molte risposte. Per me ho trovato una regola semplice (bene funziona solo per un approccio incentrato sul modello). Di solito, mi concentro solo sui diversi livelli di applicazioni.

Se il modello è composto da più entità e vi sono dipendenze tra le entità, il livello di persistenza dovrebbe riflettere tali dipendenze con le sue possibilità. Quindi, se stai usando un RDBMS, dovresti usare anche le chiavi esterne. La ragione è semplice. In questo modo i dati sono sempre validi a livello strutturale.

Qualsiasi istanza che lavora su questo livello di persistenza può fare affidamento su di esso. Suppongo che stai incapsulando questo livello tramite l'interfaccia (servizio). Quindi ecco il punto in cui finisce il design e inizia il mondo reale.

Osservando i tuoi punti, in particolare i riferimenti tra database . In tal caso, sì, non dovrebbe esserci un riferimento implementato nello stesso RDBMS, ma nel servizio. Ma prima di seguire questa strada, non sarebbe meglio considerarlo già durante la progettazione?

Significa, se so già, che ci sono parti che devono essere memorizzate in un DB diverso, quindi posso metterle già lì e definirle come modello separato. Giusto?

Stai anche sottolineando che l'implementazione di questo nel codice è più flessibile . Giusto, ma non sembra che tu abbia a che fare con un design incompleto? Chiediti, perché hai bisogno di maggiore flessibilità?

Il problema delle prestazioni, a causa dei controlli di integrità nel DB, non è reale. L'RDBMS può controllare tali cose molto più velocemente di qualsiasi implementazione da parte tua. Perché? Bene, devi affrontare l'interruzione dei media, RDBMS no. E può ottimizzare tali controlli anche usando le sue statistiche

Quindi vedi, tutto torna al design. Ovviamente puoi dirlo adesso, ma cosa succede se appare un requisito sconosciuto, un punto di svolta? Sì, potrebbe accadere, ma tali cambiamenti dovrebbero essere progettati e pianificati allo stesso modo. ; O)

Hai delle risposte molto buone ma qualche punto in più

L'integrità dei dati è ciò che un database è progettato per fare

Fare una corretta concorrenza come una cancellazione FK a livello di applicazione sarebbe orrendo

La competenza nell'integrità dei dati è con un DBA

A livello di programma si inserisce, si aggiorna, si aggiorna in blocco, si inserisce in blocco, si cancella in
blocco ... Thin client, client di spessore, client mobile ....
L'integrità dei dati non è l'esperienza di un programmatore - un sacco di codice duplicato e qualcuno farà casino su

Supponi di essere stato violato: in entrambi i casi sei nei guai, ma un hacker può fare un sacco di danni attraverso un piccolo foro se non c'è protezione di integrità nel database

Potrebbe essere necessario manipolare i dati direttamente tramite SQL o TSQL
Nessuno ricorderà tutte le regole dei dati

La tua domanda non ha senso: se puoi cambiare il database, è il codice, se non puoi cambiare il database, dovrai creare i tuoi vincoli altrove.

Un database che è possibile modificare ha lo stesso codice di qualsiasi riga di ruby, javascript, c # o ada.

La domanda su dove porre un vincolo nel sistema dovrebbe ridursi a affidabilità, costi e facilità di sviluppo.

Ci sono tonnellate di buone risposte qui. Aggiungerò che se hai un'app scritta nella lingua Y, puoi creare un codice simile al vincolo del database in Y. E poi qualcuno vuole accedere al tuo database usando la lingua Z, dovrai scrivere di nuovo lo stesso codice. Dio ti aiuti se le implementazioni non sono esattamente le stesse. O quando un utente aziendale esperto si connette al database utilizzando Microsoft Access.

La mia esperienza mi dice che quando le persone non vogliono usare i vincoli del database, è perché stanno effettivamente cercando di fare qualcosa nel modo sbagliato. Ad esempio, stanno provando a caricare in blocco i dati e vogliono lasciare null colonne non null, per un po '. Intendono "risolverlo più tardi" perché la situazione che ha reso critico il vincolo non nullo "non può probabilmente accadere in questo caso". Un altro esempio potrebbe essere quando stanno cercando di inserire due diversi tipi di dati nella stessa tabella.

Le persone più esperte faranno un passo indietro e troveranno una soluzione che non comporta il tentativo di aggirare un vincolo. La soluzione potrebbe semplicemente essere che il vincolo non è più corretto perché il business è cambiato, ovviamente.