La logica del modello di dati dovrebbe vivere nello schema del database?

Sì!

Perché? Perché i vincoli unici sono nell'interesse di tutti.

Ora alcuni potrebbero sostenere che l'applicazione può farlo e potrebbero persino avere casi d'uso in cui il vincolo univoco deve essere temporaneamente violato.

A cui dico "Non è un vincolo unico!"

Ovviamente si tratta di più di vincoli unici. Solo un esempio pratico

Il database NON dovrebbe essere il centro della tua applicazione. Ma dovrebbe essere l'autorità dominante di ciò che ha senso in sé. Non vado in giro a dire ai file come allocarli sul disco rigido esattamente per lo stesso motivo.

Questa è una linea che può essere offuscata e abusata. La chiave è utilizzare il database per applicare solo le regole necessarie per rendere il database affidabile in modo affidabile (indipendentemente da ciò che qualsiasi app sta tentando di fare). Non usare il database in tutti i modi possibili.

Mi piacciono i DB che dicono "OK, non ho idea di quello che stai facendo, ma è una sciocchezza proprio lì".

Come per le eliminazioni a cascata, si tratta di un'area grigia. Nel mondo degli oggetti parliamo di composizione vs aggregazione. Gli aggregati vanno e vengono, ma se sei composto da qualcosa ne hai bisogno per poter lavorare correttamente. La vita è intrecciata con la tua. Almeno dovrebbe essere se non si desidera generare eccezioni perché qualcosa ha cercato di usarti quando sei in cattivo stato.

Nel mondo del database sebbene si tratti di dati. Se cancelli un cliente significa che non hai mai venduto qualcosa a questo cliente? Hai qualche attività commerciale che cancella i clienti con i record di vendita?

Questo è un vincolo relazionale solo a causa di una necessità aziendale. Il database funzionerà correttamente memorizzando i record delle transazioni con un cliente che ora non è altro che un numero di chiave esterna. Perché l'azienda vuole eliminare i record dei clienti nessuno lo sa. Forse il team legale è arrivato sventolando un ordine del tribunale presso il team IT. Questo probabilmente interromperà alcuni rapporti, ma è così che va.

Ora se la tabella A_audit è la cronologia di tutto ciò che è mai stato nella tabella A è il business dei database. Nient'altro ha più autorità su questo tipo di cose perché questo è il lavoro dei database. Quindi una cancellazione forzata a cascata del database qui ha senso, quando è richiesta. Forse c'è un campo per alcuni dati che risulta che non avresti mai dovuto raccogliere. Ora deve essere cancellato.

Ovviamente tutto ciò dipende da ciò che stai usando delete to represent. Questo è ancora un MODELLO di dati. Quindi non c'è una sola ragione per cancellare le cose. Ecco dove le cose si complicano.

Personalmente, preferisco CR a UD. È sorprendente quanto puoi lavorare in questo modo. Ma i nostri ideali sono raramente i nostri risultati.