Ha senso inserire vincoli nel codice invece che nel database? [duplicare]

Ovviamente è più flessibile per consentire tutto. Discutere di questo è un gioco perdente. Il punto di vincoli, tipi, informazioni nascoste ecc. Ecc. È che abbiamo lentamente e dolorosamente realizzato che la flessibilità totale non è buona per noi . Siamo troppo inclini agli errori ad assumerci questa responsabilità, e siamo troppo cattivi nel giudicare le nostre stesse capacità per fare da soli il giusto compromesso.

In questo caso, un database con colonne nullable non può garantire molte delle cose che costituiscono il vantaggio di avere un database relazionale in primo luogo. REST è un buon modo per accedere alle cose, ma semplicemente non può fornire il tipo di assicurazioni (come l'atomicità, la durabilità, ecc.) Che le persone assumono dall'uso di database. Forse tutto ciò non ha alcuna importanza nel tuo particolare sistema, ma ne dubito davvero.

Questa linea di ragionamento è valida se non si hanno mai errori o errori nel codice .

È necessario un singolo bug nel codice dell'applicazione per far sì che un NULL venga salvato nel database. Anche se questo bug viene rapidamente scoperto o risolto, il NULL rimane nel database e causerà il fallimento di altre parti del codice in modi oscuri, poiché il resto del codice viene scritto con l'aspettativa che questo campo non sia mai NULL. Non puoi davvero liberarti del NULL, dato che non sai quale dovrebbe essere il valore corretto. Quindi ora devi riscrivere tutto il codice per gestire il caso speciale in cui questo campo è NULL.

Ovviamente potrebbero esserci anche degli errori nella progettazione schema / vincoli, ma questo porterebbe solo alla corruzione dei dati nel caso sfortunato in cui c'è un bug nello schema e un bug corrispondente nell'applicazione codice. Quindi sei ancora molto meglio protetto. In ogni caso, la logica applicativa è in genere molto più complessa e più veloce nel cambiare lo schema del database, e quindi più incline agli errori.

Ovviamente dovresti ancora convalidare e applicare i vincoli di business a livello di applicazione. Sto solo segnalando il rischio che solo lo faccia a livello di applicazione e che il database non rifiuti dati non validi.

Il motivo per cui i vincoli nel database sono in genere il miglior punto di partenza, è a causa della concorrenza.

Se la tua applicazione supporta più di un singolo utente, o è un'applicazione web in cui è possibile avere più persone che aggiornano i dati, oppure una singola persona con più schede del browser aperte, i vincoli a livello di applicazione sono soggetti alle condizioni della competizione: Multiple le persone potrebbero essere aggiornate allo stesso tempo allo stesso tempo. Anche i pre-controlli a livello di applicazione richiedono millisecondi e in un breve lasso di tempo due persone potrebbero commettere le modifiche contemporaneamente, ignorando così i vincoli a livello di applicazione.

I database hanno risolto da tempo le condizioni di competizione che influiscono sull'inserimento, l'aggiornamento e l'eliminazione degli stessi dati, che chiamano concorrenza.

Non dimentichiamo inoltre che i dati possono finire nel database senza passare per l'applicazione. Un DBA può accedere ed eseguire uno script SQL.

Mettiamo i vincoli nel database semplicemente perché non dobbiamo programmare la concorrenza e le condizioni di gara nel livello dell'applicazione, e i dati possono essere inseriti o aggiornati senza passare attraverso l'applicazione.