Perché dovrei usare chiavi esterne nel database? [chiuso]

1

Nei miei oltre 10 anni di esperienza nel settore IT, non ho mai utilizzato chiavi esterne in nessuno dei miei progetti e non ne ho mai sentito il bisogno. Ho lavorato con database professionali che avevano vincoli di chiavi estranee.

Ora sono in una posizione in cui stiamo costruendo nuove applicazioni / database e penso che dovrei usare chiavi esterne o no? Questo sarà un prodotto professionale. Prenderò in considerazione l'implementazione di questo nei miei progetti esistenti se ottengo una risposta soddisfacente.

Questo articolo su perché utilizzare le chiavi esterne risolve esattamente le mie preoccupazioni . Il punto cruciale è

  1. Mantiene l'integrità referenziale (sì, ma può essere mantenuto anche senza)
  2. Lavoro investigativo più facile (ovviamente)
  3. Prestazioni migliori (non ne sono del tutto sicuro)

La mia domanda è se devo usare chiavi esterne o posso vivere senza di essa. Quali sono i pro e i pro forti di uno sviluppatore che ha lavorato in tali scenari.

Esempio: Ora una parte importante dell'uso di chiavi esterne è la complessità aggiunta alla progettazione. Ad esempio una semplice eliminazione potrebbe non funzionare, o potrebbe cancellare altri record di cui non sei a conoscenza. Consideriamo sencio in risposta alla mia domanda.

Ho un database con user e user_comments tabelle.

create table user(
user_id int not null identity,
user_name varchar(50),
...
)

create table user_comment(
comment_id int not nul identity,
user_id int,
CONSTRAINT FK_USER_USERID FOREIGN KEY (user_id)     
    REFERENCES user (user_id)
    ON DELETE CASCADE    
    ON UPDATE CASCADE 
)

Qui, se elimino un utente, tutti i suoi commenti verranno automaticamente cancellati. So che posso cambiare questo comportamento, ma la mia domanda è, sono le chiavi esterne che vale la pena utilizzare con la sua complessità aggiuntiva, che sono vantaggi e svantaggi degli utenti di SE.stackexchange . Sto forse guardando alcune storie dell'orrore? Qualcuno può commentare come migliora le prestazioni?

    
posta Noname 23.07.2018 - 08:18
fonte

2 risposte

16
  1. It maintains referential integrity (yes but can be maintained without it too)

Sei tecnicamente corretto che se sei in grado di mantenere l'integrità referenziale da solo, non hai bisogno che il vincolo esista. Ma con la stessa logica, non hai bisogno di un'assicurazione contro gli incendi fintanto che la tua casa non brucia, e non hai bisogno di un'assicurazione sanitaria finché non ti ammali.

Sebbene tecnicamente corretto, l'asserzione sottostante di quanto tu possa fare in modo impeccabile è semplicemente un fallimento nel riconoscere la possibilità che tu (o qualsiasi altro sviluppatore) commetta un errore.

La presenza involontaria dell'integrità referenziale senza chiavi esterne funziona senza problemi. Ma più tardi, quando vuoi recuperare i dati, ti si riempie la faccia.

  • Chi ha impostato questi dati?
  • Quando l'hanno impostato?
  • Perché l'hanno impostato su questo valore?

Queste domande diventano molto difficili da rispondere.

La presenza involontaria dell'integrità referenziale con chiavi esterne esplode in faccia immediatamente .

  • Chi ha impostato questi dati? Hai fatto.
  • Quando hanno provato a impostarlo? In questo momento.
  • Perché l'hanno impostato su questo valore? Dal momento che lo stai facendo adesso, sei logicamente la migliore fonte per sapere cosa stai cercando di fare.

Risolvere i problemi diventa molto più facile quando sei già all'origine del problema.

  1. Easier Detective work (of course)

Immagino tu intenda la cosa che ho appena descritto.

  1. Better Performance (I am not quite sure)

Can someone comment how how it improves performance?

Le chiavi esterne non migliorano le prestazioni, almeno non direttamente. Il guadagno in termini di prestazioni è ottenuto dall'uso di indici . Accade solo che PK e FK vengano indicizzati automaticamente perché vengono utilizzati molto frequentemente per la ricerca, rendendoli obiettivi principali per l'ottimizzazione della ricerca.

In here, if I delete a user, all his comments will automatically be deleted.

Questo non è inerente a una chiave esterna. Questo è inerente all'impostazione di ON DELETE CASCADE sulla chiave esterna. Le eliminazioni in cascata sono una funzionalità piacevole, ma non sono il caso di utilizzo principale delle chiavi esterne. Il caso d'uso principale è il mantenimento dell'integrità referenziale.

My question is should I use foreign keys or can I live without it. What are strong pros and cons from a developer who worked in such scenarios.

my question is, is Foreign keys worth using with its added complexity

Non vedo la complessità di cui stai parlando.

Se dichiari di essere già in grado di gestire l'integrità referenziale, significa che dovrei essere in grado di mettere un FK nella tua colonna FK-less, e non sarai in grado di notare che ho inserito un FK nella tua colonna. Non c'è alcuna complessità nell'avere l'FK.

L'impostazione dell'FK è banale. Sì, richiede un comando SQL esplicito, ma il comando è molto copy / pastable:

CONSTRAINT unique_name FOREIGN KEY fk_column_name REFERENCES pk_table (pk_column_name)

Mentre lo sviluppatore pigro in me si chiede se la denominazione di un vincolo sia davvero necessaria, le altre informazioni che è necessario aggiungere sono logicamente sempre necessarie per impostare una relazione tra due colonne. A parte il nome, è semplicemente il più semplice possibile.

Il guadagno in termini di prestazioni derivante dall'avere un indice sulla colonna è inerente ad avere un FK sulla colonna. Impostare un indice senza un FK è complesso quanto impostare un FK:

CREATE INDEX unique_name ON fk_table_name (fk_column_name)

Quindi, di nuovo, non vedo la complessità aggiunta dall'effettiva utilizzo di una chiave esterna.

    
risposta data 23.07.2018 - 09:18
fonte
1

Se elimini un utente, perché dovresti vuoi per mantenere i loro commenti orfani in giro?

Il vantaggio principale di un archivio dati relazionale è la possibilità di garantire che tali anomalie non si verifichino mai. Se ti piacciono e vuoi tali garanzie, allora è una buona idea implementarle al livello più basso possibile, cioè costruirle nel motore del database, perché è più veloce e più sicuro che farlo tu stesso.

Se non li vuoi, allora stai meglio con un archivio dati non relazionale. Ma usare un modello di motore e poi rifiutare di sfruttare uno dei suoi maggiori vantaggi sembra stranamente inutile.

    
risposta data 23.07.2018 - 08:31
fonte