Il giorno 25 gennaio 2013 10:39, gabriele renzi [email protected] ha
scritto:
constraint, perch blasfemo far fare al db quello che non si pu
fare a livello applicativo…assolutamente d’accordo con te.
Esistono constraint e constraint.
E’ passato un periodo in cui qualche malato faceva delle verifiche
applicative (es. et >= 18) con le
constraint, e poi usava le ECCEZIONI per gestire gli errori di
validazioni.
E’ un approccio che insegnano all’universit, ed SBAGLIATO: usare le
eccezioni per tutto ci che non
‘eccezionale’ un errore, perch queste sono ‘costose’.
Le verifiche “applicative” vanno fatte a livello applicativo, da cui le
validazioni in rails.
Al contrario, un approccio sensato usare le constraint a livello di
database per garantire la consistenza,
se qualcosa va storto il nostro db deve rimanere sempre consistente.
Quindi, ok a ‘unique’, ‘foreign keys’, ecc…
Nel caso queste siano violate, per me tranquillamente OK andare in
eccezione anche nei confronti dell’utente finale,
cos mi arriva una bella notifica e so che sta succedendo qualcosa di
storto.
I casi di errore ‘normale’ devono essere gestiti dalle validazioni a
monte.
Ciao,
Matteo