Ragionando dal punto di vista del DBA ti dico che se devono esserci dei vincoli a garanzia dell'integrità dei dati, questi DEVONO essere messi lato database. Non mi riferisco tanto al carattere maiuscolo nell'iniziale del nome (che tutto sommato può essere "ricostruita" a posteriori o comunque facilmente deducibile anche solo in fase di reportistica) quanto a controlli più "forti" che minerebbero l'integrità (e di conseguenza l'affidabilità) dei dati. Mi riferisco, ad esempio, al campo Sesso (valgono solo M o F), al campo provincia (deve essere una sigla presente in una tabella relazionata), ecc.
Inoltre tieni anche conto che qualunque base dati, anche se utilizzata dalla migliore applicazione di questo mondo è comunque soggetta ad importazioni batch, rettifiche direttamente sul db, fusioni con altri database, ecc. In tutte queste condizioni se non ci fossero i constraint lato database ogni volta minacceremo l'integrità logica dei dati (ed il più delle volte tali situazioni emergono dopo mesi o anni rendendo più difficoltosa la bonifica).
E' altrettanto vero che un controllo implementato lato database e non lato applicazione richiederebbe un onere aggiuntivo (trascurabile quanto vogliamo ma pur sempre presente) legato al fatto che il vincolo verrebbe verificato solo dopo aver premuto il tasto "salva", occupato risorse di rete, risorse di database, ecc.
Probabilmente la soluzione migliore è quella, quindi, di implementare parte dei controlli ANCHE lato applicazione scegliendo magari tra gli "errori" più frequenti che commettono gli utenti nell'inserimento dei dati. Ad esempio quella dell'iniziale maiuscola è sicuramente uno di questi ma non interverrei segnalando l'errore ma bensì correggendo automaticamente la cosa.
In sostanza il mio parere alla "domanda breve" che hai posto è: "implementare *sempre* e *tutti* i vincoli lato db e valuta quali duplicare anche lato applicazione".

Just my 2 cents...