Newsgroup: it.comp.www.php
Titolo: Tecnica di gestione DB

Salve!
Sto realizzando in questi giorni un progetto in PHP con DB Postgres al
posto del "solito" mysql.
Credo sia superfluo enunciare le differenze fra i due DB, più che altro
con Postgres ho la possibilità di creare una struttura molto più
complessa e, cosa non da poco, gestire meglio i dati (procedure, vincoli
e via dicendo).
Ora, quello che mi chiedo è questo: avendo un DB che permette di
effettuare controlli parecchio precisi sui dati, come è meglio gestire
i dati stessi? Mi spiego meglio con un esempio.
Supponiamo di avere la tabella utenti definita basilarmente come:
create table users(
 id int2 not null,
 nome varchar (30),
 email varchar(50)
);
e di impostare un controllo sul campo email tale che, per essere
inserito, un record debba avere il campo 'email' che contenga una @
(check email like '%@%', per farla semplice).
Dato per assunto che il controllo sopra sia corretto, quale strada è
meglio seguire fra le due seguenti:
1) ricevo il dato in ingresso ( $_POST['email']), controllo via PHP che
   tale dato contenga una @, se non la contiene visualizzo un errore e
   se la contiene faccio una insert e controllo (tramite pg_affected_rows)
   che il record sia entrato
2) ricevo il dato in ingresso, lancio la insert senza preoccuparmi del
   valore [1] e, a  seconda del valore ritornato da pg_affected_rows
   visualizzo un messaggio di errore o di conferma
Al momento, mi sto orientando verso la seconda soluzione visto che posso
sfruttare una caratteristica del DB per "risparmiare" codice
nell'applicazione ottenendo comunque il risultato che cerco. Sto anche
lavorando parecchio a livello di DB per inserire nella struttura del DB
stesso un insieme di vincoli e condizioni tali per cui c'è un margine
minimo di errore nella coerenza dei dati con quelle che sono le
richieste.
Sinceramente, non ci vedo nulla di male ( :-P ) nel lavorare in questo
modo, anche se non sono del tutto convinto che lasciar lavorare SOLO il
DB nel caso in cui possa lavorare da solo sia una soluzione ideale;
soprattutto, non mi convince il fatto di dover "sfruttare" degli errori
( = mancate corrispondenze nei vincoli) a livello di
inserimento/modifica/cancellazione dei dati per sapere se è possibile o
meno proseguire.
Qualcuno ha commenti o esperienze in merito?
So che in molti casi tutti questi vincoli a livello di DB si fanno anche
per semplificare eventuali migrazioni dell'applicazione da un linguaggio
ad un altro, ma sinceramente questo non è il mio caso! :-)
Ciao e grazie a chiunque voglia esprimere un parere sulla cosa!
--ev
[1]: un controllo generico sui dati, per evitare injections et similia
     viene comunque sempre effettuato, i valori non entrano alla cieca.
-- 
      My Right brain Left,
but my Left brain is always Right

 ha scritto nel messaggio
news:sh0tdd...@192.168.2.100...


 Intanto devo dirti che sei stato chiaro.
Per favore, 
http://wiki.news.nic.it/QuotarBene
-- 
I am what I am, I do what I can
Do. Or do not. There is not try.

    visualizzo un messaggio di errore o di conferma
La prima, per il semplice fatto che esistono dei vincoli e/o controlli
sui dati di input che non e' possibile verificare lato DB.
-- 
I am what I am, I do what I can
Sei un newbie? Leggi questo 
http://url.repository.biz/go/3C
Vuoi supportarmi? 
http://url.repository.biz/go/3E


 sui dati di input che non e' possibile verificare lato DB.
["la prima" = controllare via PHP i dati]
A parte il fatto che al momento, per controlli tutto sommato semplici,
non ho avuto problemi di "impossibilità di realizzazione", ovviamente
sono intesi i controlli *fattibili* sul DB.
Alla faccia di questo, la risposta cambia?
Ciao!
--ev


 Alla faccia di questo, la risposta cambia?
IMHO far fare al DB controlli tipo "questo testo deve essere una email"
e' illogico perche' ti impone di implementare il controllo sul DB in un
modo tale da restare molto vincolato alla piattaforma scelta e sei
comunque obbligato ad implementare la gestione degli errori lato PHP,
tralasciando tutti quei controlli che non puoi fare lato DB.
-- 
I am what I am, I do what I can


 tralasciando tutti quei controlli che non puoi fare lato DB.
Domanda da non esperto:
Ma affidare troppi controlli sul DB(penso all'email), non ne penalizza la 
performance quando aumentano le richieste contemporanee?
Danilo 

 esperienza in merito!
Anch'io! ^_^
Ciao!
--ev


 tralasciando tutti quei controlli che non puoi fare lato DB.
Guarda, al momento con Postgres non ho trovato limiti se non la mia poca
esperienza. Ho le regexp, che al momento mi permettono di eseguire tutti
i controlli di cui ho bisogno, per quello che "non c'è" uso trigger
prima o dopo gli inserimenti per controllare i dati ...
Insomma, al momento non c'è stato niente che non sono riuscito a fare
(tranne un vincolo "CHECK dato not in (select bla bla bla)", purtroppo
non si possono usare le query nei check ... :-( ), adesso voglio provare
a modificar un paio di funzioni che uso con i trigger che mi permettono
di ritornare una stringa di errore in modo da avere un controllo ancora
più "preciso" su cosa avviene nella base dati ...


 poca esperienza.
Qualsiasi controllo che non e' solo basato sui dati non funzionera'
etc. etc. E comunque ti leghi in modo indissolubile al DB.


 i dati stessi? Mi spiego meglio con un esempio.
Secondo me per alcune cose e` meglio far gestire gli errori al DB, per
altre all'applicazione.
Per esempio, un vincolo di univocita` di un campo lo farei gestire al
DB, che mi risparmia di fare una select preventiva (con lock del DB in
scrittura) prima di ogni insert/update.
Un controllo come quello che dici tu (email) e` meglio farlo lato
client.
Questo perche` ti risparmi il ping-pong client-server (se e` in locale
non te ne accorgi, ma se il DB e` una macchina fisicamente diversa dal
webserver puo` diventare pesante), eviti di sovraccaricare il DB-server
(che ne avra` gia` abbastanza di query contemporanee) e soprattutto
gestisci meglio il tutto.
Metti che dopo un anno che tu hai messo un check sul DB con determinati
parametri, viene cambiato il modo di gestione dei dati. Dovresti entrare
nel DB e cambiare il trigger, rischiando magari che ti blocchi tutte le
insert/update perche` alcuni dati non sono conformi, o che si blocchi
tutto finche` non sistemi. Potresti anche non avere piu` sottomano il
DB, magari perche` e` da un cliente.
Con la soluzione lato client correggi quello e ti riservi un po' di
tempo per verificare i dati, oltre a poter spedire il software al
cliente senza dover andare li` a mettere mano al suo DB (magari in
produzione...).
Bye.