Come progettare questo database per evitare la dipendenza ciclica?

Ci sono due tabelle:

Utente
Indirizzo

L'utente contiene un riferimento all'indirizzo.

L'indirizzo contiene le colonne CreatedBy e ModifiedBy, che fa riferimento all'utente.

Come posso progettare questo database per evitare una dipendenza ciclica?

database-design

— Shashi
fonte

Sei sicuro che ModifiedBy non sia un riferimento all'utente del database che ha apportato la modifica, piuttosto che all'utente delle applicazioni (che risiederebbe nella tabella User)? Ad ogni modo, non importa davvero. Non vedo perché c'è un problema reale?

— Philᵀᴹ

Quale verrà creato per primo. Come creato da e modificato da è un dato indispensabile. E la tabella degli utenti non dovrebbe avere addressid come null .. Problema pollo-uovo. Mentre risolvo questo creando una nuova tabella UserAddress che contiene il riferimento per userid e addressid

— Shashi,

Potresti sempre usare vincoli differiti se il tuo DBMS li supporta.

— Colin 't Hart,

NB Il modello relazionale supporta l'esecuzione di due inserimenti o aggiornamenti come un'unica operazione atomica, è un vero peccato che non sia supportato in SQL (poiché i vincoli differiti - anche se li ho suggeriti - sono piuttosto orribili).

— Colin 't Hart,

Risposte:

Invece di cercare suggerimenti e trucchi (inclusi i vincoli differiti), suggerirei di progettare semplicemente la tua via d'uscita da questo "blocco di riferimento" - quindi prova qualcosa del genere:

I fatti

L'utente(UserID) esiste.
L'indirizzo è(AddressID) stato creato dall'utente(UserID) .
L'indirizzo è(AddressID) stato creato alla data(DateCreated) .
L'indirizzo è(AddressID) stato modificato da ultimo dall'utente(UserID) alla data(ModifiedOn) .
Utente(UserID) risiede Indirizzo(AddressID) dal Data(ValidFrom) .

vincoli

Each L'indirizzo è stato creato exactly one dall'utente . It is possible that more than one L'indirizzo è stato creato the same dall'utente .
Each L'indirizzo è stato creato alla exactly one data . It is possible that more than one L'indirizzo è stato creato alla the same data .
For each and Data indirizzo , l' that indirizzo è stato modificato at most one dall'utente alla that data .
For each and Data utente , l' that utente risiede l' at most one indirizzo dalla that data .

Logico

inserisci qui la descrizione dell'immagine

Per quanto riguarda l'indirizzo obbligatorio, verifica che a livello di applicazione e avvolgi le istruzioni di caricamento in una transazione, in questo modo otterrai tutto o niente.

— Damir Sudarevic
fonte

Non hai altra scelta che creare la dipendenza ciclica in 2 operazioni come sotto perché una tabella non esiste quando crei la prima.

CREATE TABLE A (A_ID INT PRIMARY KEY, B_FK INT);
CREATE TABLE B (B_ID INT PRIMARY KEY, A_FK INT REFERENCES A(A_ID));

ALTER TABLE A ADD B_FK INT;

Se si desidera evitare la dipendenza ciclica. Quindi è necessario rimuovere un vincolo REFERENCES oppure è possibile aggiungere un riferimento DELETE e UPDATE CASCADE in un modo. Potresti anche implementare un TRIGGER se la tua logica è alquanto complessa.

— PollusB
fonte

La rimozione dei vincoli rimuove la dipendenza ciclica dalla definizione, ma non dal design. È possibile aggiungere una tabella Eventi per registrare UserID e AddressID che hanno creato o modificato l'ultimo indirizzo, ma ciò sposta la dipendenza di un passo più avanti. In caso contrario, se la tabella User avesse le colonne CreatedBy e ModifiedBy, la dipendenza ciclica esisterebbe in una tabella. Ciò è simile a una tabella dei dipendenti con una colonna supervisore in cui il supervisore è anche un dipendente. Come ha indicato Phil - Nessun problema.

— Leigh Riffel,

@LeighRiffel Sono d'accordo. Ma la tabella Eventi che proponi in realtà rimuove tutte le dipendenze cicliche.

— ypercubeᵀᴹ

@ypercube Effettivamente lo fa; non sono sicuro di come ho incrociato quel filo. Per essere chiari, probabilmente non dovresti creare una tabella Eventi anche se rimuove la dipendenza ciclica.

— Leigh Riffel,

Comunque, non credo che questa risposta risolva il problema. La domanda (penso) riguarda come evitare il percorso ciclico, non come creare gli FK con il percorso ciclico in primo luogo.

— ypercubeᵀᴹ