Il mio RDBMS multi-server o la mia applicazione devono gestire l'integrità referenziale del database?

Elementi come chiavi esterne, vincoli, valori predefiniti e così via devono essere gestiti dal sistema di gestione del database (in questo caso, MS SQL 2005) o dall'applicazione? Ho sentito opinioni da entrambe le parti e onestamente non sono sicuro di quale strada fare.

È possibile che si verifichino più server / database e non penso che le chiavi esterne possano essere utilizzate su server collegati. Oltre a ciò, ci sono alcuni riferimenti circolari nella progettazione del database che mi impediscono di utilizzare ON UPDATE CASCADEtutto.

Il database è MS SQL 2005 (possibilmente 2008) e tutte le interazioni con esso dovrebbero passare attraverso l'applicazione.

Se è possibile che il DB venga modificato all'esterno dell'applicazione, si desidera i vincoli nel database. Se il DB è e sarà sempre nient'altro che il back-end dell'applicazione, puoi lasciarli fuori, anche se li documenterei per ogni evenienza e probabilmente li terrei dentro se il colpo di performance non fosse troppo male. (Il software Peoplesoft funziona in questo modo - i vincoli sono nel software e (non lo sto inventando) esegue tutto come SYS su Oracle.)

Volete che cose del genere vengano monitorate dall'applicazione, in modo che possa reagire in modo intelligente e, al massimo, restituire all'utente un messaggio di errore del database.

E, sì, si tratta di una doppia copertura, ma senza di essa probabilmente otterrai un danneggiamento dei dati prevenibile o una cattiva interfaccia utente.

Idealmente, entrambi. Non dovresti fare in modo che il DB lo gestisca, ma di nuovo, se l'app fornisce dati che il DB rifiuterà, si tratta di un errore di runtime, quindi l'app dovrebbe avere almeno un codice dedicato a preservare l'integrità referenziale. Inoltre, impostare i giusti vincoli in SQL nel DB è molto più semplice che impostare il codice per il suo lato client, quindi farlo sul DB riduce notevolmente la quantità di lavoro che devi fare.

Se è importante, lascia che sia il database a gestirlo. In questo modo, non devi preoccuparti che qualcuno acceda al database al di fuori della tua applicazione e cambi o immetta alcuni dati incoerenti o duplicati. A meno che non si tratti di roba specifica per applicazioni di alto livello (come "solo gli utenti del dipartimento X con una classe di accesso ZZZ dovrebbero appartenere al gruppo 999"), ma di solito non si parla di integrità "referenziale".

Direi messo nel database. Se stai usando un framework persistente, prenderà automaticamente le chiavi.

Entrambi sono sicuramente la strada da percorrere. Avrai bisogno di una logica di convalida nel tuo codice per prevenire aggiornamenti e inserimenti errati, nonché per dire agli utenti cosa era sbagliato e come risolverlo. E avere il database lì per back-stop le cose, quindi se qualcosa è entrato e non ha funzionato attraverso la convalida, ciò non spezzerebbe le cose in modo positivo.

È necessario mantenere le cose del database di livello superiore. Ad esempio, imporre l'integrità referenziale e forse alcuni non nulli. Ma non preoccuparti di vincolare lunghezze o formati poiché è meglio renderlo interamente all'applicazione.