Dovremmo utilizzare i vincoli di chiave esterna quando persiste modelli di dominio?

Question

Qualche tempo fa ho avuto una discussione con i miei colleghi circa la persistenza di modelli di dominio e se dobbiamo rispettare i vincoli di chiave esterna a livello di database.

La mia prima reazione è stata che l'uso stesso di un database relazionale implicita l'applicazione di tali vincoli, ma alcuni hanno sostenuto che il database dovrebbe essere visto come nient'altro che un meccanismo di persistenza e quindi ci dovrebbe evitare di mettere qualsiasi logica di business in esso. Abbiamo finito, non utilizzando i vincoli di chiave esterna.

Ecco la mia domanda (spero che non sia troppo generico): è buona norma rispettare i vincoli di chiave nelle tesi casi

?

Answer 1

Imporre vincoli, ma non fare affidamento su di loro nel vostro logica di business

• No attività logica sul database: Sono d'accordo con il principio. E se il tuo non SQL il codice di business si basa sui vincoli del database per controllare la coerenza del database, allora si dovrebbe ripensare la logica di business.
• Non c'è niente di male di avere vincoli del database oltre per la logica di business. Soprattutto perché le cose come l'integrità referenziale con chiavi esterne e altri vincoli unici sono facili da fare e RDBMS stanno facendo quel lavoro per voi in modo molto efficiente, senza molta manutenzione.
• Will non usare Indici sul database troppo, perché non è puramente persistenza correlate?
• Ricerca e correzione di bug software potrebbe richiedere un certo tempo, ma sicuramente non vogliono spendere ancora più tempo pulizia o (peggio) di perdere alcuni dati, proprio perché ti salvato un disturbo di scrittura di script di una sola linea per una FK. Davvero: il vostro get qualcosa gratis qui e la vostra rifiutano
?
• [EDIT-1]: si può garantire che i dati nel database sarebbe gestito SOLO tramite la vostra applicazione? Ci sembrano essere sempre le eccezioni, per lo più di power-utenti, che fanno a volte (molto raramente :-) commettere errori ed eseguire alcune istruzioni SQL per pulire-up il codice, status update (a valori non validi a causa di errori di battitura), ecc.
• [EDIT-2]: Edificio dominio guidato modello non è una scusa per non assumere un buon DB Admin. Utilizzando ORM non è una scusa per non assumere buon sviluppatore di DB.

Ma se tu e la tua squadra in grado di scrivere software senza bug e gestire tutti i possibili scenari di eccezione nel codice (compresi i guasti hardware / rete / manichino-utente / programmatore di errori), allora "Hei, perché preoccuparsi di ridondanti vincoli FK ...." - -teaser -

Answer 2

Credo di sì, lo considero non tanto qualcosa per la logica di business, ma evitando di dati "cattivi" da essere inseriti nel database. Una volta che il database diventa molto grande di questi vincoli impedirà mal di testa nel futuro.

Ciò vale in particolare entrerà in vigore quando si dispone di più sviluppatori di sviluppo di applicazioni contro gli stessi dati. Questo farà sì che così possono entrare solo i dati validi. Avendo vincoli controllati in 1 posto invece che in applicazioni X è certamente utile.

Answer 3

Mi sento come ignorare strumenti realmente utili (integrità dei dati a livello di database) per il bene di una metodologia di sviluppo puro è controproducente. I database sono veramente bravo a questo genere di cose ... lasciarli fare.

Ad un certo punto ogni metodologia comincia ad abbattere e devi solo essere pratico.

Answer 4

Ho usato a pensare così, ma il mio parere è cambiato da quando ho iniziato a scrivere un sacco di sistemi di risorse-oriented. In genere, molto più che i vincoli di chiave solo stranieri sono tenuti a convalidare un pezzo di dati - ad esempio, un biglietto che è in stato "assegnato" deve avere una valida "assigned_to" valore, e così via. Tutte queste norme deve essere collocato in una routine di convalida di qualche tipo, e mentre in teoria non potrebbe male di avere la convalida in più a livello di database, se il vostro convalida a livello di applicazione è in funzione, controllando l'estero vincolo di chiave è solo sprecato cicli. Molto peggio, però, ora che hai avuto la logica del tuo modello di dati ripetuto in due luoghi - il codice di convalida ei vincoli del database.

Pensare in questo modo: si vorrebbe spostare qualsiasi altra logica di applicazione al database (ad esempio, tramite le stored procedure) se non è necessario? Se non si è stati costretti a farlo da considerazioni sulle prestazioni, credo che la risposta dovrebbe essere generalmente "no".

Answer 5

"La mia prima reazione è stata che l'uso stesso di un database relazionale implicita l'applicazione di tali vincoli, ma alcuni hanno sostenuto che il database dovrebbe essere visto come nient'altro che un meccanismo di persistenza e quindi ci dovrebbe evitare di mettere qualsiasi logica di business in esso. abbiamo finito, non utilizzando i vincoli di chiave esterna ".

Sì, beh, la maggior parte mediocre vince sempre quel tipo di dibattito mera forza dei numeri, ahimè.

Se si desidera continuare a combattere quella battaglia, si potrebbe chiedere i tuoi avversari come intendono mantenere a chiunque di utilizzare "editor di database diretta" (ala DB2 soccorso, SPUFI, ...) e come intendono impedire a nessuno di corrompendo il database utilizzando tali strumenti (che bypassare i loro vincoli di business programmati per definizione).

Answer 6

Se si vuole seguire il Driven Design paradigma dominio, allora la risposta sarebbe sì per qualsiasi cosa all'interno di un aggregato, e non per tutti i collegamenti cross-aggregate.

In quasi tutti i casi, si desidera qualcosa sotto l'Aggregate Root da eliminare quando la radice stessa viene eliminato, e in modo da avere le chiavi esterne che rappresentano questo, con eliminazioni a catena, permettono di raggiungere questo obiettivo a livello di database. Si potrebbe anche avere i repository fare la cascata si cancella se non si vuole fare ad un livello di DB, ma il punto si trova ancora che i bambini di aggregazione non dovrebbero esistere senza il Root.

Per preoccupazioni cross-aggregate, probabilmente a che fare con le decisioni di business da quello che dovrebbe accadere quando uno o l'altro è stato rimosso. Spesso si vorrà affrontare questo modo asincrono per consentire la scalabilità, e così il modello di dominio finisce per essere finalmente coerente. Pertanto, non ha senso in questi casi per far rispettare le chiavi esterne come ci sarà una finestra di tempo in cui l'uno o l'altro tasto potrebbe non esistere.

Speranza che aiuta! E per maggiori informazioni, sicuramente check out libro di Evans' su Domain Driven Design -. ed i numerosi collegamenti in tutto il web troppo