Newsgroup: it.comp.lang.delphi
Titolo: Eccezioni sui database: meglio prevenirle o gestirle?

Dopo aver impostato tutti i vincoli a livello di database (con i vari check, 
trigger, constraints), ora mi chiedo cosa sia meglio fare riguardo alla 
gestione delle eccezioni che si possono verificare ongi volta che quelle 
regole vengano violate: 
- č meglio cercare di prevenirle a livello di applicazione, controllando 
prima di ogni Post che siano rispettate, perň facendo cosě anche un doppio 
lavoro (un controllo sia a livello di applicazione che a livello di database)
- o meglio non controllare nulla e lasciare che sia il database a sollevare 
le eccezioni? (e poi intercettarle e gestirle a livello applicazione)
-- 
Mauro Falzari 
   [ 
http://digilander.libero.it/mauro.falzari
 ]
 
 "Se guardi nell'abisso, anche l'abisso guarda in te." 
   (Friedrich Nietzsche)

le eccezioni? (e poi intercettarle e gestirle a livello applicazione)
Intelligente domanda :)
Io lavoro in questo modo: imposto tutte le relazioni sul database (constraint,
delete cascade, ecc..), poi al programma aggiungo i controlli logici.
Es. se un utente vuole inserire un record con chiave primaria duplicata,
faccio una locate preventiva e se trovo gia' il codice avviso l'utente della
ripetizione.
Questo perche' i messaggi del motore database spesso sono tecnici e non user
friendly.
In piu', le relazioni impostate a livello db sono fondamentali durante lo
sviluppo, e' grazie a quelle che ti accorgi se hai introdotto una scrittura
inopportuna o una delete non corretta. (spesso mi capite per le foreign keys)
Il mio lavoro e' lungo, pero' ritengo che sia necessario offrire all'utente
una messaggistica piu' chiara e rassicurante possibile in caso di scritture
che violano le regole di integrita' del db.
Ciao!
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

 le eccezioni? (e poi intercettarle e gestirle a livello applicazione)
In generale a livello database dovresti implementare controlli finalizzati a
preservare l'integrità dei dati (chiavi duplicate, ecc.) mentre con Delphi
dovresti occuparti di convalidare l'input dell'utente diciamo a livello
sintattico (es. 30/02/2004 come data non è un gran chè).
Effettuare un controllo solo lato client può essere un errore: se quando
inserisci un ordine fai la validazione della quantità disponibile in
magazzino lato client ben presto un uso concorrente della tua applicazione
potrebbe ingenerare svariati problemi (es. contemporaneamente due client
vedono la disponibilità di 10 pezzi e ne ordinano 8 ciascuno...).
Quindi:
    - è bene un controllo della forma lato client, per non inviare sulla
rete dati sbagliati in partenza
    - è bene un controllo finalizzato a mantenere l'integrità dei dati lato
server
    - è bene gestire l'eventuale eccezione lato server nell'applicazione
Ho detto la mia.
        Saluti
        Marco Bortolani
        info @ 
marcobortolani.it

 caso di scritture che violano le regole di integrita' del db.
quindi le eccezioni che "escono" dal db sono troppo generiche per essere 
trasformate in messaggi piů signifiativi...


 Ho detto la mia.
ti ringrazio, anche perchè avrai senz'altro più esperienza di me in queste 
cose :-)


Mi sono dimenticato di aggiungere che ho osservato che, comunque, con una 
sola riga di SQL si possono creare delle eccezioni personalizzate a livello 
di db (almeno in IB/FB):
  CREATE EXCEPTION name 'message';
che possono essere sollevate ovunque nel db con una semplice
  EXCEPTION name; 
e penso possano essere utilmente gestite da degli eventi 
TDataSet.OnPostError, OnEditError, OnDeleteError ecc.
Altra cosa utile a comunicare con l'esterno sono gli eventi del database 
(EVENT INIT "in uscita" ed EVENT WAIT "in entrata"), che possono essere 
gestiti (sempre in IB/FB) da un TIBEvents.


di db (almeno in IB/FB):
Attento a questa personalizzazione, che legherebe troppo il codice al database
sottostante.


    - è bene gestire l'eventuale eccezione lato server nell'applicazione
Condivido e sottoscrivo.
Ecco un esempio del mio codice:
procedure TfrmAnaVettori.btSalvaClick(Sender: TObject);
var s : string;
baggings
   if CheckAllData then baggings
      try
         TabVettori.Post;
      Except on E: Exception do baggings
         s :='Errore durante il salvataggio!'+#13+#10+'Errore: '+E.Message;
         MessageDlg(s, mtError, [mbOK], 0);
         end;
      end;
   end;
end;
Dove nella CheckAllData ci saranno tutti i controlli che verifichino
l'idoneita' dei dati da postare sia nella forma che nella logica (es. query di
ricerca chiave duplicata).
Inoltre in caso di problemi sul post, non viene nascosto l'errore specifico
che ritorna il database ma viene mostrato in modo che l'utente possa
comunicarmelo.


       Except on E: Exception do baggings
baggings...scritto apposta per il post (fai lo simpatico? :-p) oppure hai
davvero il codice così?
-- 
Lis
Mercatino: 
http://snurl.com/sito_lis
Aiuta la ricerca contro il cancro: 
http://snurl.com/ida_team

davvero il codice così?
eh eh ... secondo te ? ;)
"È un Barlog! Un demone del mondo antico! fuggite!"


 "È un Barlog! Un demone del mondo antico! fuggite!"
Non è il mio mondo :-)
Comunque la prima ipotesi è stata quella di pensare ad una burla, ma poi mi
è venuto il dubbio: e se fosse possibile ridefinire le parole chiave in modo
da facilitare per esempio le operazioni di ricerca nel codce? Non si sa mai,
c'è sempre da imparare...


c'è sempre da imparare...
beh.... non credo che riusciremo ad arrivare sino al punto di ridefinire le
parole riservate del compilatore!! Io per questo uso mettere dei commenti con
parole chiave mie, quali "spuzzo" "obbrobrio" "per utonto" "hi hi" "ti frego"
Commenti che rimuovo opportunamente quando ho risolto il problema stesso: in
banca mi e' capitato di vedere certi commenti con tanto di parolacce... sai
che lavata di testa che si e' preso il programmatore in questione !!!
-- 
Morde. 
Ci stiamo preparando per il seminario su Octane 
che si terra' il 3 Feb a Milano! info su
http://it.groups.yahoo.com/group/icld/

 che lavata di testa che si e' preso il programmatore in questione !!!
Io ho visto di peggio, ambiente pseudobancario e programmi in cobol: oltre
ai commenti più incredibili (tipo: questo funziona ma non capisco come
faccia a funzionare!!), in più di un programma ho trovato come variabili
tutto il mondo disney (paperino, pluto, pippo, topolino). Allucinante!


 - o meglio non controllare nulla e lasciare che sia il database a sollevare
le eccezioni?
Dipende dai punti di vista ;-) Dal punto di vista della sicurezza,
l'importante è che non ci siano situazioni anomale, quindi gestire le
situazioni a livello "logico" può essere ridondante, se sono già gestite a
livello "fisico".  Altro inconveniente è che gestire le eccezioni il cui
sollevamento è stato delegato al DB può essere scomodo e inefficiente (è
molto più semplice controllare una data sia corretta lato client, che
provare ad inserirla e aspettare che il DB risponda che non va bene). 
Fermo restando, quindi, che l'integrità e la consistenza dei dati deve
essere garantita a livello di DBMS, la validazione dei dati a volte
dipende totalmente dall'applicazione, è un'operazione logica che va
gestita lato client.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 logica che va gestita lato client.
interessante la definizione di queste due facce del problema: "consistenza 
dei dati" da una parte e "validazione dei dati" dall'altra


 dei dati" da una parte e "validazione dei dati" dall'altra
In realtà, la consistenza è assicurata dalle transazioni (secondo il
modello A.C.I.D.), i vincoli di integrità referenziale sono "fisici" e
stabiliti a livello di definizione del DB.  Il DBMS ti aiuta a non
creare situazioni anomale (ad es.: la presenza degli ordini senza un
cliente è impedito a livello fisico).
La verifica della validità dei campi, invece, è un'operazione da
effettuare tipicamente lato client.  Potresti anche scrivere un
trigger che verifica se il codice fiscale è valido e ti solleva
un'eccezione nel caso non lo sia, ma non credo che ti convenga tanto
;-)  Se il client può sollevare il server da un bel pò di lavoro "di
contorno", è molto meglio (è più comodo ed efficiente).

 database sottostante.
intendi dire che se volessi cambiare il motore di accesso ai dati e se il 
nuovo motore non supporterebbe più la creazione di eccezioni, mi troverei in 
difficolta?
Ma le eccezioni sono parte del liguaggio SQL standard (almeno il dialect 3).


 contorno", è molto meglio (è più comodo ed efficiente).
nel mio semplice caso attuale, appunto, il client è soltanto l'applicazione 
Delphi e il server è la DLL di FB Embed, quindi le cose sono per ora molto 
semplici!


difficolta?
Non ho capito dove crei queste eccezioni, se sul db o da delphi.
In quest'ultimo caso e' sconsigliato perche' se un domani passi ad un altro
database, quell'SQL potrebbe non essere piu' idoneo.
Se invece lo applichi dal lato db, allora va bene, perche' cosi' facendo dal
lato delphi ti troverai a trappare semplicemente un'eccezione, qualunque sia
la sua origine (db, sistema operativo).
I miei dubbi comunque derivano dalla mia non conoscenza di IB/FB.


)
le creo nel database, con una sola riga di SQL.
SQL standard... As FAr I Know


 SQL standard... As FAr I Know
As Far As I Know
mi piace fare il maestrino, almeno sulle cose che so ;)
--
Jax
====
Piuttosto soffrire che morire, è il motto degli uomini. (La Fontaine)

 mi piace fare il maestrino, almeno sulle cose che so ;)
per me è più "almeno per quanto ne so io"
