linux user group brescia

On Mon, Oct 17, 2005 at 04:29:08PM +0000, cartolina wrote:

> questa e' una critica interessante.
> ma si puo' risolvere
> e' un cerchio:
> la tabella delle definizioni e' l'input del select in html
> in html viene definita la descrizione
> il trigger infila l'integer in tabella se esiste la descrizione e se e' 
> uguale a quella della tabella definizioni
> in tutto cio' non vedo dove perdo di sincronizzazione.

innanzitutto e' sbagliato a priori direi. poi comunque ti puo' capitare
un momento in cui devi aggiornare queste informazioni e le aggiorni
dalla parte sbagliata cosi' le vedi solo in alcuni casi.
 
> >infatti avrei dovuto specificare meglio la risposta:
> >
> >si, le trigger sono sintatticamente corrette e servono a un sacco di
> >cose. la tua idea mi ha fatto venire in mente un uso ulteriore a cui
> >non avevo pensato.
> >
> cioe'?

quello di farle funzionare in qualche modo durante gli inserimenti in
piu' tabelle contemporaneamente.
 
> >comunuque non ho ancora capito bene quello che vuoi fare
> >indipendentemente dalle trigger. ;)
> 
> volevo solo semplificarmi la vita, ovvio che corro sempre il rischio di 
> complicarmela
> anziche' scrivere :
> select desc1,desc2,desc3 from tab1 natural join tab2 natural join tab3 
> where campo1 = 1
> select desc1,desc2,desc3 from tab1 where campo1_id = 1

natural join?? si usa ancora quella roba li'? :)

io farei:

select
	tab1.campoa,
	tab1.campob,
	tab2.campoc
from
	tab1,tab2,tab3
where
	tab1.campod=tab2.campoe and
	tab2.campof=tab3.campog and
	tab1.campoa=1

molto piu' ordinata e pulita. e se sei in (terza???) forma normale non
dovresti avere problemi.
 
> quando i campi delle query e le tabelle iniziano ad essere una ventina,
> scrivere natural join 20 volte inizia a diventare antipatico

non sei obbligato a scriverlo. :)

ciao!

-- 
BOFH excuse #250:

Program load too heavy for processor to lift.