Sì. Puoi sempre assicurarti che i dati siano conformi alle regole all'interno dei programmi applicativi prima di aggiungere i dati al database. Ci sono due cose che rendono questo difficile da fare.
Il primo è la natura imperativa di quasi tutti i linguaggi di programmazione. Non esiste un modo semplice per dichiarare che un determinato campo non debba mai essere lasciato nullo o dovrebbe sempre fare riferimento a un referente esistente o dovrebbe sempre essere in tale e tale dominio. Tali regole dichiarative sarebbero generalmente controproducenti quando si tratta comunque di variabili di programma.
Quindi devi controllare ogni percorso di esecuzione per assicurarti che non infranga le regole. L'incapsulamento aiuta, ma non abbastanza.
Il secondo è che più programmi applicativi possono interagire con lo stesso database. Ho visto database in cui dozzine di programmi, parti di diverse applicazioni, condividono dati leggendo e scrivendo sullo stesso database. Accertarsi che nessuno di questi programmi vada in fumo è quasi impossibile.
Al contrario, i vincoli DBMS sono dichiarativi, relativamente semplici e vengono applicati ogni volta che è necessario nel contesto delle transazioni che manipolano i dati. I trigger possono rendere l'applicazione più flessibile, al costo di seguire la rotta imperativa piuttosto che quella dichiarativa.
La normalizzazione è rilevante solo per alcuni tipi di violazione dell'integrità dei dati. L'obiettivo delle forme normali da 2NF a 5NF è di ovviare alla possibilità di lasciare il database in uno stato contraddittorio. Le forme normali lo fanno assicurando che un singolo fatto venga memorizzato solo in un posto. È giusto o sbagliato, ma non è contraddetto da un altro fatto memorizzato altrove nel database.
Questo può essere estremamente utile per ridurre l'incidenza delle violazioni di integrità. Ma ci sono molti casi di integrità che non hanno nulla a che fare con la normalizzazione. L'integrità referenziale è uno di questi casi.
In quasi tutti i casi in cui un programmatore rinuncia all'integrità forzata del DBMS perché "i miei programmi non hanno mai errori logici" o "il DBMS è troppo lento", il programmatore o il suo successore hanno vissuto per pentirsene. Ricorda, il valore dei dati spesso supera il sistema che lo ha catturato.
Nel caso in cui ci hai dato, dove Detroit, CA è noto per essere sbagliato, come puoi essere sicuro? Come fai a sapere che non c'è un piccolo piccolo sobborgo, da qualche parte in California, a cui è stato dato il nome "Detroit"? Si può supporre che, se non è nel database, allora non può essere vero. Ma questa ipotesi può facilmente tornare a morderti.