Quali sono i vantaggi vincoli forniscono a un database?

Question

Mi rendo conto che questa domanda può sembrare un po 'sul lato "verde", ma dopo il numero di database "commerciali" che ho incontrato "impresa" o ho cominciato a fare questa domanda. Quali sono i vantaggi di vincoli di fornire a un database? Mi sto chiedendo di più su vincoli di chiave esterna, piuttosto che i vincoli unici. Non offrono miglioramenti delle prestazioni, o solo l'integrità dei dati?

Sono stato un po 'sorpreso dal numero di database relazionali senza chiavi esterne o anche senza chiavi primarie specificate (solo vincoli sui campi che sono non nullo o un vincolo univoco sul campo).

Pensieri?

Answer 1

"solo" l'integrità dei dati? Lo dici come se fosse una cosa minore. In tutte le applicazioni, è fondamentale. Quindi sì, esso prevede che, ed è un enorme vantaggio.

Answer 2

L'integrità dei dati è quello che offrono. Semmai hanno un costo delle prestazioni (molto minore almeno uno).

Answer 3

Essi forniscono sia integrità delle prestazioni e dati, e il secondo è fondamentale per qualsiasi sistema serio. Rabbrividisco ogni volta che vedo un database senza chiavi esterne e dove tutta l'integrità viene fatto attraverso trigger (se non del tutto). E ho visto un po 'di quelli là fuori.

Answer 4

Di seguito, supponendo che si ottiene il vincolo a destra, in primo luogo: -

• I tuoi dati saranno validi rispetto al vincolo
• Il database conosce i vostri dati saranno validi rispetto al vincolo e può usare questo quando l'esecuzione di query o l'aggiornamento del database (ad esempio, la rimozione di un inutile unirsi per una query su una vista)
• Il vincolo è documentata per i futuri utenti del database
• Una violazione del vincolo sarà catturato nel più breve tempo possibile; non in qualche processo non correlati in seguito che non riesce

Answer 5

In teoria relazionale, un database che permette di dati incoerenti in realtà non è un database relazionale. Le chiavi esterne sono necessari per l'integrità e la coerenza dei dati per mantenere il database "relazionale"; vale a dire il modello logico del database è sempre corretto.

In termini pratici, di solito è più facile definire una chiave esterna e lasciare che la maniglia del motore DB assicurandosi che la relazione è valida. Le altre opzioni sono:

• niente - la corruzione dei dati garantita ad un certo punto
• DB trigger - che di solito è più lento e meno performante
• codice di applicazione - che finirà per causare problemi quando o si dimentica di chiamare la destra codice o un'altra applicazione accessi il database.

Answer 6

Dati è un bene. Un sacco di libri di testo affermano che.

Ma in realtà è sbagliato. Si dovrebbe piuttosto dire "dati corretti è un bene, di dati non corretti è una responsabilità".

E vincoli del database offrono la migliore garanzia possibile che i dati siano corretti.

Answer 7

In alcuni DBMS (ad esempio Oracle) vincoli può effettivamente migliorare le prestazioni di alcune query, dal momento che l'ottimizzatore può utilizzare i vincoli di acquisire conoscenze sulla struttura dei dati. Per alcuni esempi, vedere questo Oracle Magazine articolo .

Answer 8

Direi che tutti i vincoli richiesti devono essere nel database. vincoli di chiave esterna evitare che i dati inutilizzabili. Essi non sono un bello avere - sono un requisito meno che non vogliate un database inutile. Le chiavi esterne possono influire negativamente sulle prestazioni di eliminazioni e aggiornamenti ma che è OK. E 'meglio prendere un po' di più per fare una cancellazione (o per dire l'applicazione di non cancellare questa persona perché ha ordini nel sistema) o per eliminare l'utente, ma non i suoi dati? La mancanza di chiavi esterne possono causare problemi imprevisti e spesso gravi nei interrogazione dei dati. Per esempio i rapporti di costo possono dipendere tutte le tabelle con i dati relativi e quindi potrebbero non riuscire a mostrare i dati importanti a causa di una o più tabelle non hanno nulla a unirsi a.

vincoli unici sono anche un requisito di qualsiasi databse decente. Se un campo o un gruppo di campi devono essere univoci, non riuscire a definire questo al leve database è tocreate problemi di dati che sono estremamente difficili da risolvere.

Non parlare di altri vincoli, ma si dovrebbe. Qualsiasi regola di business che deve essere sempre applicato a tutti i dati nella tabella deve essere sempre applicato nel database attraverso un tipo di dati (come ad esempio un tipo di dati che DataTime willnot accetta '02 \ 31 \ 2009' come una data valida), un vincolo (diciamo uno che non consente che il campo abbia un valore maggiore di 100) o tramite un trigger è la logica è così complessa che non può essere gestito da un vincolo ordinaria. (Trigger sono difficili da scrivere, se non si sa cosa si sta facendo, quindi se avete la logica di questo complesso, si spera avere adatabase professionale sulla vostra squadra.) L'ordine è importante. Tipi di dati sono la prima scelta, seguito da vincoli, seguita da trigger come ultima scelta.

Answer 9

Più semplice codice Application

Una cosa bella che forniscono è che il codice dell'applicazione ha a che fare molto meno controllo degli errori e convalida. Contrasto questi due pezzi di codice e moltiplicare per migliaia di operazioni e si può vedere c'è una grande vittoria.

get department number for employee  # it's good coz of constraints
do something with department number

vs.

get department number for employee
if department number is empty
    ...
else if department number not in list of good department numbers
    ....
else
    do something with department number

Naturalmente, le persone che ignorano i vincoli probabilmente non mettere un sacco di fatica in validazione del codice in ogni caso ...: - /

Oh, e se i vincoli dati cambiano, si tratta di un problema di configurazione del database e non un problema di modifica del codice.

Answer 10

Vincoli di integrità sono particolarmente importanti quando si integra diverse applicazioni che utilizzano un database condiviso.

Si può essere in grado di gestire correttamente l'integrità dei dati nel codice delle singole applicazioni (e anche se non lo fai, almeno i dati di rotta effetti solo su tale applicazione), ma con più applicazioni si ottiene peloso (e almeno ridondante ).

Answer 11

"Oh, e se i vincoli dati cambiano, si tratta di un problema di configurazione del database e non un problema di modifica del codice".

A meno che non si tratta di un vincolo che scompare dalla progettazione. In questo caso, non v'è sicuramente un impatto codice, perché alcuni codice potrebbe essere stato scritto che dipende da quel vincolo rimosso essere lì.

che deve sempre essere preso in considerazione quando "laxing" o "rimozione" alcun vincolo dichiarato.

Oltre a questo, si è ovviamente completamente a destra.