Avrebbe mai senso che l'applicazione imponesse l'integrità del database invece di avere chiavi esterne, verificare vincoli, ecc.?
Quanto di miglioramento delle prestazioni ci si può aspettare per non applicare l'integrità del database attraverso strumenti di database interni?
Risposte:
A dire il vero, non solo vedrai molte perdite di prestazioni dovute a vincoli di chiave esterna nel database, ma vedrai miglioramenti delle prestazioni. Query Optimizer di SQL Server è basato sul concetto di chiavi primarie e forzate, nonché su altri tipi di vincoli di dati. Se questi sono presenti e applicati, l'ottimizzatore può trarne vantaggio per ottenere prestazioni migliori. Ecco un post sul blog con un semplice esempio che lo mostra in azione.
Se ti trovi in un caso limite in cui hai davvero più inserti che letture (e gli aggiornamenti e le eliminazioni richiedono letture, quindi di solito si aggiungono al conteggio delle letture), allora potrebbe avere senso rimuovere i vincoli dai dati per le prestazioni, forse . Ma poiché la stragrande maggioranza dei database è orientata alla lettura, stai sacrificando le prestazioni, non migliorandole.
E nulla di tutto ciò menziona il fatto che l'integrità dei dati è gestita meglio nel database poiché è necessario crearla una sola volta in cui, come se si eseguisse tutto il lavoro nel codice, potrebbe essere necessario farlo più volte per più app (a meno che non si progetta il tuo livello di accesso ai dati con attenzione e richiede che ogni app acceda al db per passare attraverso quello stesso livello).
Se stai usando un sistema di database relazionale, dico, perché non usarlo davvero. Se non hai bisogno di dati relazionali, vai con Hadoop o qualcos'altro.
Molti sviluppatori di applicazioni la pensano così.
Quando sei tentato di delegare l'integrità dei dati al codice dell'applicazione, pensa "Ogni programmatore e ogni applicazione che colpisce questo database da adesso fino alla fine dei tempi devono ottenerlo perfettamente, sempre."
Quali sono le probabilità?
Anche se c'è un miglioramento delle prestazioni, è trascurabile rispetto al ritorno dell'integrità referenziale e dell'integrità generalizzata dei dati.
Sono lontani i giorni in cui un database è un archivio di dati stupido. Sfrutta la potenza che offre RDBMS.
I guadagni in termini di prestazioni non sono tutto, specialmente su scala così ridotta. Ma quando scopri di avere una presunta relazione di chiave esterna che l'applicazione dovrebbe applicare, e si scopre che non è una chiave primaria nella tabella di riferimento, allora ti preoccuperai molto del guadagno delle prestazioni (se ce ne sono, posso non parlarne sui dettagli).
È prassi comune eliminare vincoli (chiavi esterne, CHECK, ecc.) E indici se si sta eseguendo un carico di dati sufficientemente ampio e riattivare / implementare successivamente i vincoli e gli indici. Tale convalida ha un costo in termini di tempo. Ciò presuppone che non sia possibile utilizzare la sintassi di caricamento di massa specifica del database (incl. Minimizzazione della registrazione).
È impossibile dire quanto ci si aspetti da un aumento delle prestazioni: ogni situazione è unica (tipi di dati, design, ecc.). L'unico modo per sapere veramente è testare.
Ci sono alcune volte in cui i vincoli si frappongono:
Quando è necessario utilizzare l' ereditarietà a tabella singola (STI). Immagina di vendere sia a privati che a organizzazioni. Avrai bisogno di una singola tabella "Party" la cui riga è un individuo o un'organizzazione. STI significa che hai bisogno di alcuni campi annullabili che non dovrebbero essere nulli. L'ereditarietà delle tabelle di classe risolve questo problema, ma questo è più difficile per alcuni ORM. ActiveRecord di Ruby supporta solo STI, ad esempio.
Quando è necessario supportare versioni bozza di un'entità, potrebbe non essere completamente valido. È possibile memorizzare una bozza come json, ma è più difficile riutilizzare lo stesso identificativo sul client: immagina che sia stata salvata con id = 5, modificata per non essere valida e salvata automaticamente come draftid = 99. In questo caso, probabilmente tutti i tuoi campi dovrebbero essere nullable.