È necessario creare una chiave esterna nella tabella padre o nella tabella figlio?

Qual è la differenza? Se ho queste due tabelle:È necessario creare una chiave esterna nella tabella padre o nella tabella figlio?

CREATE TABLE Account (Id int NOT NULL) 

CREATE TABLE Customer (AccountId int NOT NULL)

E voglio una chiave esterna che collega i due, che di seguito si deve fare e perché?

Opzione 1:

ALTER TABLE [dbo].[Customer] WITH CHECK 
    ADD CONSTRAINT [FK_Accounts_Customers] FOREIGN KEY([AccountId]) 
    REFERENCES [dbo].[Account] ([Id])

Opzione 2:

ALTER TABLE [dbo].[Account] WITH CHECK 
    ADD CONSTRAINT [FK_Accounts_Customers] FOREIGN KEY([Id]) 
    REFERENCES [dbo].[Customer] ([Id])

fonte

2013-02-21 scottm

Di solito lo metto su un tavolo che non può vivere senza l'altro (quando questo si applica). Ma dipenderà da qualunque cosa renda le vostre domande più semplici, qualunque cosa abbia più senso da un punto di vista concettuale dei dati ... e quei due esempi possono essere opposti, anche. – entonio

vorrei usare una chiave esterna dal bambino al genitore. La domanda del racconto è: cosa succede se è necessario eliminare una delle entità?

fonte

2013-02-21 17:36:18

In questo caso, se elimino un cliente, non voglio che si sovrapponga agli account, ma se elimino un account, questo dovrebbe essere a cascata per i clienti. – scottm

Quindi l'account può vivere senza cliente ma il cliente non può vivere con l'account. Quindi il cliente dovrebbe indicare il conto e non viceversa. -> Opzione 1 –

@ scottm dovresti scrivere la logica nella tua procedura DELETE che gestisce la cascata. Non sono un grande fan - e non mi fido molto - delle opzioni ON CASCADE attualmente disponibili in SQL Server. –

Dipende dal contesto. Ogni cliente ha un cliente? Qual è il genitore? Sembra che un Account abbia più Clienti, nel qual caso il riferimento appartiene alla tabella Clienti.

Ora, detto questo, si prega di chiamare le entità CustomerID e AccountID ovunque. Potrebbe sembrare ridondante sul tavolo principale ma il nome dovrebbe essere coerente in tutto il modello.

fonte

2013-02-21 17:36:44

Accordo del mille per cento sulla denominazione. Non dovresti usare ID come nome del campo per un PK - prefisso sempre con il nome dell'entità. Ciò è particolarmente importante quando si utilizzano gli ORM che utilizzano la mappatura basata sulla convenzione poiché questo è spesso il modo in cui si aspettano che il modello appaia. Il rovescio della medaglia è che devi qualificare i tuoi oggetti quando scrivi dei join, ma 'a) 'dovresti farlo comunque e' b) 'con un ORM probabilmente non scriverei molto/nessun T-SQL – Charleh

Se dovessi usare Strutture ispirate a rotaie e rotaie che non sono vere. In tal caso, quando id è una chiave primaria, è solo "id" come "customers.id" - è abbastanza ovvio. Quando si fa riferimento come foreign_key, si fa 'accounts.customer_id 'in questo modo. – konung

Un FK (chiave esterna) indica al DBMS che i valori per le sottoprodotti di un elenco di colonne devono apparire altrove come valori per le sottocomporthe per un elenco di colonne. Ogni volta che ciò accade (e non è già implicito in altre dichiarazioni) dichiara l'FK. Se in aggiunta si desidera applicare un'azione CASCADE alla tabella di riferimento su una modifica alla tabella di riferimento, dichiararla.

(Non c'è niente di speciale CASCADE che non poteva essere offerto per le situazioni non-FK. Viene solo su spesso con FKS, e c'è un grafico esplicito di FKS con cui limitare ragionevolmente le loro interazioni.)

Se c'è un FK cycle allora sarà necessario utilizzare i trigger. La decisione su quale/i vincolo/i viene/o applicato/i in modo dichiarativo è & che per trigger deve considerare il grafico dei vincoli (desiderati).

fonte

2017-07-24 22:05:01 philipxy

È necessario creare una chiave esterna nella tabella padre o nella tabella figlio?

risposta

Problemi correlati