From linfo2003 a libero.it  Sat Jun  2 13:51:51 2007
From: linfo2003 a libero.it (Giovanni R.)
Date: Sat Jun  2 14:35:12 2007
Subject: [Db] Trigger o altro?
Message-ID: <466159D7.4050005@libero.it>


Ciao a tutti.

Ho due tabelle, Prodotti e Offerte, connessi da una relazione 1:N.

Quando vado a visualizzare l'elenco dei prodotti, vorrei visualizzare
anche il numero di offerte associato al singolo prodotto (e anche altre
informazioni simili, ma lasciamo perdere).

Posso agire, credo, in almeno tre modi:

  1) una query su Offerte per ogni prodotto;
  2) una unica query con inner join sulle due tabelle;
  3) l'uso di un nuovo campo, Numero_Offerte, in Prodotti.

Vorrei evitare le prime due soluzioni per questioni di prestazioni.

Siccome vorrei anche evitare di dover andare "manualmente" a modificare
via PHP quel nuovo campo ogni volta che viene fatta o ritirata
un'offerta, avevo pensato che forse i dbms mettono a disposizione
qualche strumento automatico per aggiornare Prodotti.Numero_Offerte in
base alle query INSERT/DELETE effettuate su Offerte.

Avevo pensato ai trigger, che ahimé attualmente ancora non conosco: devo
proprio imparare ad usarli, oppure c'è un'altra soluzione? :-)

In realtà il problema non sono i trigger in sé, ma il linguaggio, spesso
proprietario, utilizzato per scrivere le relative funzioni: siccome non
amo scrivere codice poco portabile, ho sempre rinviato lo studio delle
stored procedure. :(

Ciao, Giovanni

ps. al limite, per ora creerò le mie "pseudo stored procedure" in PHP...
From linfo2003 a libero.it  Sat Jun  2 14:01:07 2007
From: linfo2003 a libero.it (Giovanni R.)
Date: Sat Jun  2 14:44:15 2007
Subject: [Db] UK e NULL
In-Reply-To: <465E8B15.1000307@pleiade.it>
References: <465E8B15.1000307@pleiade.it>
Message-ID: <46615C03.40700@libero.it>

Domenico L. wrote:
>     scopro a mie spese che per mysql (ver 4.0) che i campi facenti parte 
> di un Unique index se valorizzati a null estromettono il record in 
> questione dal controllo di univocità.... che bello....

A suo tempo non fu una bella scoperta neppure per me. :-(

Standard SQL-92:

"A unique constraint is satisfied if and only if no two rows in a table
have the same non-null values in the unique columns."

Standard SQL-2003:

"If there are no two rows in T such that the value of each column in one
row is non-null and is not distinct from the value of the corresponding
column in the other row, then the result of the <unique predicate> is
True; otherwise, the result of the <unique predicate> is False."

cfr. http://bugs.mysql.com/bug.php?id=8173
(l'avevano riportato come bug, ma non lo è)

Ciao, Giovanni
From cristiano a verondini.it  Sat Jun  2 14:37:08 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Sat Jun  2 15:20:06 2007
Subject: [Db] Trigger o altro?
In-Reply-To: <466159D7.4050005@libero.it>
References: <466159D7.4050005@libero.it>
Message-ID: <67DD3295-3448-4D96-8CBA-6D038918F285@verondini.it>


On 02/giu/07, at 13:51, Giovanni R. wrote:

> Avevo pensato ai trigger, che ahimé attualmente ancora non conosco:  
> devo
> proprio imparare ad usarli, oppure c'è un'altra soluzione? :-)

	Hai bisogno di due meccanismi:

	(1) trigger: in pratica chiedi al DBMS di eseguire del codice in  
determinati momenti (di solito su inserimenti/cancellazioni di record  
dal DB)
	(2) stored procedure: codice che viene eseguito dal DBMS


> In realtà il problema non sono i trigger in sé, ma il linguaggio,  
> spesso
> proprietario, utilizzato per scrivere le relative funzioni: siccome  
> non
> amo scrivere codice poco portabile, ho sempre rinviato lo studio delle

	Se ne è parlato qualche giorno fa. Io sono della tua stessa  
opinione, ma ci sono 'correnti' diverse. Ogni approccio ha ovviamente  
i suoi pro e contro.

	Diciamo che il metodo preferito dal DB è quello dei trigger e stored  
procedure. L'alternativa è di gestire il tutto a livello applicativo.  
Nel primo caso perdi ovviamente in portabilità, ma dovresti  
guadagnare in robustezza. Nel secondo caso aumenti la portabilità, ma  
diventa più complesso gestire l'integrità del DB.

		Cris

-- 
Cristiano Verondini
http://www.verondini.it  ---  [ICQ 114 190]





From linfo2003 a libero.it  Sat Jun  2 15:49:27 2007
From: linfo2003 a libero.it (Giovanni R.)
Date: Sat Jun  2 16:32:34 2007
Subject: [Db] Trigger o altro?
In-Reply-To: <67DD3295-3448-4D96-8CBA-6D038918F285@verondini.it>
References: <466159D7.4050005@libero.it>
	<67DD3295-3448-4D96-8CBA-6D038918F285@verondini.it>
Message-ID: <46617567.8020707@libero.it>

Cristiano Verondini wrote:
> 	Diciamo che il metodo preferito dal DB è quello dei trigger e stored  
> procedure. L'alternativa è di gestire il tutto a livello applicativo.  
> Nel primo caso perdi ovviamente in portabilità, ma dovresti  
> guadagnare in robustezza. Nel secondo caso aumenti la portabilità, ma  
> diventa più complesso gestire l'integrità del DB.

Stavo pensando che non sarebbe stato male se si fosse potuto dire al
dbms di eseguire, invece che la stored procedure, una certa operazione
via shell (./myscript.php, eheh), ovviamente passando gli argomenti
necessari allo script ed aspettando la risposta. In questo modo potrei
cercare di coniugare la robustezza dei trigger, con la semplicità (cioè
il fatto che io già lo conosca) e la portabilità di PHP. Anche se
probabilmente perderei le ottimizzazioni del dbms.

Ipotizziamo comunque io crei un trigger per ogni query DELETE su
Offerte. Se cancello un utente da Utenti, il dbms cancella
automaticamente anche le sue offerte (on delete cascade) da Offerte: in
questo modo la procedura definita dal trigger verrebbe eseguita? A
quanto ho capito, sì. E verrebbe eseguita N volte, con N uguale al
numero di offerte dell'utente, giusto?

Nel mio caso (per ogni prodotto ogni utente può fare una e una sola
offerta) non è un grosso problema, ed anzi è necessario eseguire N volte
la procedura.

Ma prendiamo ad esempio eBay, dove un utente può fare anche più di
un'offerta per ogni prodotto: in quel caso l'ideale sarebbe quello di
raggruppare (group by) per prodotto, ed eseguire un'unica volta la
procedura. Se ad es. un utente ha fatto 10 offerte sul progetto x, è
inutile decrementare 10 volte x.Numero_Offerte: basterebbe decrementarlo
di 10 unità un'unica volta alla "fine" del "processo di on delete".

Mi sa che però non esiste un trigger su tale evento.
L'unica soluzione che mi sovviene è quella di decrementare di 10 unità
x.Numero_Offerte e poi cancellare le 10 righe dalla tabella Offerte,
quando viene richiamata per la prima volta la procedura scatenata dal
trigger *before* delete per l'utente in questione: il problema è che,
così facendo, si va a cancellare la riga che sta per essere cancellata.

In sintesi, che succede se faccio una query delete e poi nella procedura
del trigger "before delete" cancello il record che il dbms si apprestava
a cancellare? mi sa che verrebbe generato un "record not found"... :-/

Al limite, comunque, si può pensare di cancellare solo le altre 9 righe
e lasciare che il dmbs cancelli la decima. Però, accidenti, non è che
sia una soluzione così elegante. :-)

Alla fine forse è meglio far eseguire la procedura 10 volte, o trovare
soluzioni a livello applicativo...

Ciao, Giovanni

ps. scusa per la lunghezza. tra l'altro non devo neppure risolvere i
problemi di eBay :-), ma, siccome sto imparando, mi piace riflettere su
come risolverei io certi problemi: proverò a chiedere a quelli di eBay
se il loro codice sia open source. ;-)
From cristiano a verondini.it  Sat Jun  2 15:56:53 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Sat Jun  2 16:39:55 2007
Subject: [Db] Trigger o altro?
In-Reply-To: <46617567.8020707@libero.it>
References: <466159D7.4050005@libero.it>
	<67DD3295-3448-4D96-8CBA-6D038918F285@verondini.it>
	<46617567.8020707@libero.it>
Message-ID: <3BC47F5F-D70C-4C95-AA6A-F3887C9A9622@verondini.it>


On 02/giu/07, at 15:49, Giovanni R. wrote:

> Ma prendiamo ad esempio eBay, dove un utente può fare anche più di
> un'offerta per ogni prodotto: in quel caso l'ideale sarebbe quello di
> raggruppare (group by) per prodotto, ed eseguire un'unica volta la
> procedura. Se ad es. un utente ha fatto 10 offerte sul progetto x, è
> inutile decrementare 10 volte x.Numero_Offerte: basterebbe  
> decrementarlo
> di 10 unità un'unica volta alla "fine" del "processo di on delete".

	Logicamente avrebbe più senso, ma in questo caso invece di usare dei  
trigger, fai fare tutto ad una stored procedure. Quindi dal tuo  
applicativo niente più DELETE, ma semplici invocazioni della tua SP  
per la cancellazione.

> In sintesi, che succede se faccio una query delete e poi nella  
> procedura
> del trigger "before delete" cancello il record che il dbms si  
> apprestava
> a cancellare? mi sa che verrebbe generato un "record not found"... :-/

	Non puoi, direi! :)

> Al limite, comunque, si può pensare di cancellare solo le altre 9  
> righe
> e lasciare che il dmbs cancelli la decima. Però, accidenti, non è che
> sia una soluzione così elegante. :-)

	Ovviamente non è la soluzione!

> Alla fine forse è meglio far eseguire la procedura 10 volte, o trovare
> soluzioni a livello applicativo...

	Oppure usare direttamente le SP come ho scritto sopra.

-- 
Cristiano Verondini
http://www.verondini.it  ---  [ICQ 114 190]





From linfo2003 a libero.it  Sat Jun  2 16:30:41 2007
From: linfo2003 a libero.it (Giovanni R.)
Date: Sat Jun  2 17:13:47 2007
Subject: [Db] Trigger o altro?
In-Reply-To: <3BC47F5F-D70C-4C95-AA6A-F3887C9A9622@verondini.it>
References: <466159D7.4050005@libero.it>	<67DD3295-3448-4D96-8CBA-6D038918F285@verondini.it>	<46617567.8020707@libero.it>
	<3BC47F5F-D70C-4C95-AA6A-F3887C9A9622@verondini.it>
Message-ID: <46617F11.2010109@libero.it>

Cristiano Verondini wrote:
> 	Logicamente avrebbe più senso, ma in questo caso invece di usare dei  
> trigger, fai fare tutto ad una stored procedure. Quindi dal tuo  
> applicativo niente più DELETE, ma semplici invocazioni della tua SP  
> per la cancellazione.

Già, a questo non ci avevo pensato.
Non posso più rimandarne lo studio. :-)

Grazie per la disponibilità.

Ciao, Giovanni
From domenico.lorusso a pleiade.it  Mon Jun  4 09:19:26 2007
From: domenico.lorusso a pleiade.it (Domenico L.)
Date: Mon Jun  4 10:03:07 2007
Subject: [Db] Trigger o altro?
In-Reply-To: <67DD3295-3448-4D96-8CBA-6D038918F285@verondini.it>
References: <466159D7.4050005@libero.it>
	<67DD3295-3448-4D96-8CBA-6D038918F285@verondini.it>
Message-ID: <4663BCFE.6080002@pleiade.it>

Cristiano Verondini ha scritto:
>
>> In realtà il problema non sono i trigger in sé, ma il linguaggio, spesso
>> proprietario, utilizzato per scrivere le relative funzioni: siccome non
>> amo scrivere codice poco portabile, ho sempre rinviato lo studio delle
>
>     Se ne è parlato qualche giorno fa. Io sono della tua stessa 
> opinione, ma ci sono 'correnti' diverse. Ogni approccio ha ovviamente 
> i suoi pro e contro.
Io tendenzialmente sono per la soluzione SP/trigger ma in questo caso la 
soluzione giusta credo siano le join (che sia puro spirito di 
contraddizione? :-) ).

Altrimenti che lo tieni a fare un dbms?

Andrebbero analizzati altri fattori:
- dbms
- schema puramente transazionale o ibrido, quindi con una parte 
strutturata per il Dataware house?
- dimensione dei record e quindi numero di blocchi che ti aspetti nella 
tabella
- quantita di dml sulle tabelle

Ciao

-- 
Domenico L.        	 icq: 645 44 861 - msn: strahd@jumpy.it

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]

From marcello a vezz.it  Fri Jun  8 10:52:57 2007
From: marcello a vezz.it (Marcello Vezzelli)
Date: Fri Jun  8 11:37:49 2007
Subject: [Db] time is NOT now
Message-ID: <466918E9.9010305@vezz.it>

Ciao a tutti,
stavo lavorando a un sistema di aggiornamento che tiene conto di date 
precise al secondo e mi sono accorto di questa cosa..

Provate ad eseguire questo codice:

    $query="SELECT NOW()";
    if ($result=mysql_query($query,$DB)) {
        $row=mysql_fetch_row($result);
        echo $row[0].'<br>';
        echo date("Y-m-d H:i:s");
    }

Web server e MySql sono sulla stessa macchina (WAMP, Apache 2.0.59, Php 
5.2.0, MySql 5.0.24)
Quindi ci si aspetta lo stesso risultato...

e invece no!!!

2007-06-08 10:41:11
2007-06-08 10:41:00

La data riportata dal php è INDIETRO costantemente di circa 11 secondi e 
mezzo... ho confrontato con l'orologio di sistema.
Inquietante!

Qualcuno ha idea del perché? Succede anche su macchine linux?

Ciao
Marcello

From cristiano a verondini.it  Fri Jun  8 11:16:32 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Fri Jun  8 12:05:28 2007
Subject: [Db] time is NOT now
References: <466918E9.9010305@vezz.it>
Message-ID: <002f01c7a9ad$ccdfbdc0$6301a8c0@IdeaFutura.local>

>> Web server e MySql sono sulla stessa macchina (WAMP, Apache 2.0.59,
>> Php
>> 5.2.0, MySql 5.0.24)
>> Quindi ci si aspetta lo stesso risultato...
>>
>> e invece no!!!
>>
>> 2007-06-08 10:41:11
>> 2007-06-08 10:41:00
>>
>> La data riportata dal php è INDIETRO costantemente di circa 11
>> secondi e mezzo... ho confrontato con l'orologio di sistema.
>> Inquietante!

    Che succede se invece di NOW() usi SYSDATE() ? :)

        Cris

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From marcello a vezz.it  Fri Jun  8 11:27:04 2007
From: marcello a vezz.it (Marcello Vezzelli)
Date: Fri Jun  8 12:09:09 2007
Subject: [Db] time is NOT now
In-Reply-To: <002f01c7a9ad$ccdfbdc0$6301a8c0@IdeaFutura.local>
References: <466918E9.9010305@vezz.it>
	<002f01c7a9ad$ccdfbdc0$6301a8c0@IdeaFutura.local>
Message-ID: <466920E8.9030402@vezz.it>

Cristiano Verondini ha scritto:
>>>
>>> La data riportata dal php è INDIETRO costantemente di circa 11
>>> secondi e mezzo... ho confrontato con l'orologio di sistema.
>>> Inquietante!
>
>    Che succede se invece di NOW() usi SYSDATE() ? :)

$query="SELECT NOW(),SYSDATE()";
    if ($result=mysql_query($query,$DB)) {
        $row=mysql_fetch_row($result);
        echo $row[0].'<br>';
        echo $row[1].'<br>';
        echo date("Y-m-d H:i:s").'<br>';
        echo date("Y-m-d H:i:s",$_SERVER["REQUEST_TIME"]);
    }

2007-06-08 11:26:21
2007-06-08 11:26:21
2007-06-08 11:26:10
2007-06-08 11:26:10

Sempre più inquietante :D

Ciao
Marcello

From cristiano a verondini.it  Fri Jun  8 11:24:10 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Fri Jun  8 12:12:28 2007
Subject: [Db] time is NOT now
References: <466918E9.9010305@vezz.it><002f01c7a9ad$ccdfbdc0$6301a8c0@IdeaFutura.local>
	<466920E8.9030402@vezz.it>
Message-ID: <005901c7a9ae$c7e955f0$6301a8c0@IdeaFutura.local>

>> 2007-06-08 11:26:21
>> 2007-06-08 11:26:21
>> 2007-06-08 11:26:10
>> 2007-06-08 11:26:10

    Aggiungici: UNIX_TIMESTAMP(NOW()) ... :))

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190]
From cristiano a verondini.it  Fri Jun  8 11:32:17 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Fri Jun  8 12:20:33 2007
Subject: [Db] time is NOT now
References: <466918E9.9010305@vezz.it><002f01c7a9ad$ccdfbdc0$6301a8c0@IdeaFutura.local>
	<466920E8.9030402@vezz.it>
Message-ID: <006701c7a9af$e90cce50$6301a8c0@IdeaFutura.local>

>> 2007-06-08 11:26:21
>> 2007-06-08 11:26:21
>> 2007-06-08 11:26:10
>> 2007-06-08 11:26:10
>>
>> Sempre più inquietante :D

    Sul mio server ottengo:

pollon:/# echo "select now();" | mysql; date;php -r 'echo date("d/m/Y H:i") 
. "\n";'
now()
2007-06-08 11:35:10
Fri Jun  8 11:35:10 CEST 2007
08/06/2007 11:35

    Che succede sul tuo? In questo modo determiniamo se c'entra in qualche 
modo l'accesso web (e quindi apache o altro), oppure no.

        Cris

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190]


From cesare a ngi.it  Fri Jun  8 11:48:45 2007
From: cesare a ngi.it (Cesare D'Amico)
Date: Fri Jun  8 12:26:52 2007
Subject: [Db] time is NOT now
In-Reply-To: <006701c7a9af$e90cce50$6301a8c0@IdeaFutura.local>
References: <466918E9.9010305@vezz.it> <466920E8.9030402@vezz.it>
	<006701c7a9af$e90cce50$6301a8c0@IdeaFutura.local>
Message-ID: <200706081148.45516.cesare@ngi.it>

Alle 11:32, venerdì 08 giugno 2007, Cristiano Verondini ha scritto:
>     Sul mio server ottengo:
>
> pollon:/#
  ^^^^^^--------------- GRANDE!!!!!!!!!!!!
-- 
Cesare D'Amico      |  Gruppo Volta
Area tecnica        |  Web & Mkt Solutions
Tel: 045 21 000 84  |  Via Leida 8 - Verona
Fax: 045 21 000 85  |  http://www.gruppovolta.it
From marcello a vezz.it  Fri Jun  8 11:47:16 2007
From: marcello a vezz.it (Marcello Vezzelli)
Date: Fri Jun  8 12:29:00 2007
Subject: [Db] time is NOT now
In-Reply-To: <006701c7a9af$e90cce50$6301a8c0@IdeaFutura.local>
References: <466918E9.9010305@vezz.it><002f01c7a9ad$ccdfbdc0$6301a8c0@IdeaFutura.local>	<466920E8.9030402@vezz.it>
	<006701c7a9af$e90cce50$6301a8c0@IdeaFutura.local>
Message-ID: <466925A4.40009@vezz.it>

Cristiano Verondini ha scritto:
>
>    Sul mio server ottengo:
>
> pollon:/# echo "select now();" | mysql; date;php -r 'echo date("d/m/Y 
> H:i") . "\n";'
> now()
> 2007-06-08 11:35:10
> Fri Jun  8 11:35:10 CEST 2007
> 08/06/2007 11:35
>
>    Che succede sul tuo? In questo modo determiniamo se c'entra in 
> qualche modo l'accesso web (e quindi apache o altro), oppure no.

now()
2007-06-08 11:46:45
Fri Jun  8 11:46:45     2007
08/06/2007 11:46

Mi sembra coerente.

Ciao
Marcello
From cristiano a verondini.it  Fri Jun  8 11:50:38 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Fri Jun  8 12:38:56 2007
Subject: [Db] time is NOT now
References: <466918E9.9010305@vezz.it>
	<466920E8.9030402@vezz.it><006701c7a9af$e90cce50$6301a8c0@IdeaFutura.local>
	<200706081148.45516.cesare@ngi.it>
Message-ID: <009901c7a9b2$792aa820$6301a8c0@IdeaFutura.local>

>> Sul mio server ottengo:

>> pollon:/#
>   ^^^^^^--------------- GRANDE!!!!!!!!!!!!

    Sono i piccoli dettagli quelli che fanno la differenza! :))

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190]
From marcello a vezz.it  Fri Jun  8 12:01:08 2007
From: marcello a vezz.it (Marcello Vezzelli)
Date: Fri Jun  8 12:42:51 2007
Subject: [Db] time is NOT now
In-Reply-To: <466918E9.9010305@vezz.it>
References: <466918E9.9010305@vezz.it>
Message-ID: <466928E4.2040501@vezz.it>

Marcello Vezzelli ha scritto:
> Web server e MySql sono sulla stessa macchina (WAMP, Apache 2.0.59, 
> Php 5.2.0, MySql 5.0.24)

ok è ufficiale, è venerdì, tra 2 ore vado in ferie e sono un idiota.
Ho dimenticato che accedo al db tramite un tunnel.. e il db NON è sulla 
stessa macchina.
Tralasciamo che le macchine dovrebbero avere l'ora sincronizzata con il 
server di dominio.

Scusate per il polverone...
e grazie cmq a chi ha dato suggerimenti.

Ciao
Marcello

From cesare a ngi.it  Fri Jun  8 12:30:02 2007
From: cesare a ngi.it (Cesare D'Amico)
Date: Fri Jun  8 13:08:13 2007
Subject: [Db] time is NOT now
In-Reply-To: <009901c7a9b2$792aa820$6301a8c0@IdeaFutura.local>
References: <466918E9.9010305@vezz.it> <200706081148.45516.cesare@ngi.it>
	<009901c7a9b2$792aa820$6301a8c0@IdeaFutura.local>
Message-ID: <200706081230.03358.cesare@ngi.it>

Alle 11:50, venerdì 08 giugno 2007, Cristiano Verondini ha scritto:
> >> pollon:/#
> >
> >   ^^^^^^--------------- GRANDE!!!!!!!!!!!!
>
>     Sono i piccoli dettagli quelli che fanno la differenza! :))

hehehe

Il mio portatile attuale si chiama crilin, il vecchio mac pure, il 
router a casa kame... e mi fermo qua (a parte il server di sviluppo in 
ufficio che si chiama gacchan :-P )

Ciaps
     ce in giornata da venerdì-pre-weekend-al-mare ;)
-- 
Cesare D'Amico      |  Gruppo Volta
Area tecnica        |  Web & Mkt Solutions
Tel: 045 21 000 84  |  Via Leida 8 - Verona
Fax: 045 21 000 85  |  http://www.gruppovolta.it
From cristiano a verondini.it  Fri Jun  8 12:39:35 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Fri Jun  8 13:27:52 2007
Subject: [Db] time is NOT now
References: <466918E9.9010305@vezz.it>
	<200706081148.45516.cesare@ngi.it><009901c7a9b2$792aa820$6301a8c0@IdeaFutura.local>
	<200706081230.03358.cesare@ngi.it>
Message-ID: <00de01c7a9b9$4ff37e30$6301a8c0@IdeaFutura.local>


> Il mio portatile attuale si chiama crilin, il vecchio mac pure, il
> router a casa kame... e mi fermo qua (a parte il server di sviluppo in
> ufficio che si chiama gacchan :-P )

    Il mio portatile Neko, quello vecchio Pikachu. La Sun che è stata per 
anni server principale di facoltà (e che ancora esiste) Lamù. Più tante 
altre oramai perse ... :)

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From michel a ziobudda.net  Fri Jun  8 12:45:16 2007
From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli)
Date: Fri Jun  8 13:29:14 2007
Subject: [Db] time is NOT now
In-Reply-To: <006701c7a9af$e90cce50$6301a8c0@IdeaFutura.local>
References: <466918E9.9010305@vezz.it><002f01c7a9ad$ccdfbdc0$6301a8c0@IdeaFutura.local>	<466920E8.9030402@vezz.it>
	<006701c7a9af$e90cce50$6301a8c0@IdeaFutura.local>
Message-ID: <4669333C.2030406@ziobudda.net>

Cristiano Verondini ha scritto:
>>> 2007-06-08 11:26:21
>>> 2007-06-08 11:26:21
>>> 2007-06-08 11:26:10
>>> 2007-06-08 11:26:10
>>>
>>> Sempre più inquietante :D
>
>    Sul mio server ottengo:
>
> pollon:/# 
"Sembra talco ma non è / serve a darti l'allegria, / se la mangi o la 
respiri, / ti dà subito l'allegria!"

:)

Non si scappa dagli anni 80 :)

M.

-- 
Michel 'ZioBudda' Morelli                       michel@ziobudda.net
Consulenza sistemistica in ambito OpenSource.
Sviluppo applicazioni web dinamiche (LAMP+Ajax)
Telefono: +39-3939890025 --  Fax: +39-0291390660

http://www.ziobudda.net                         ICQ: 58351764  
http://www.ziobuddalabs.it                      Skype: zio_budda
http://www.ajaxblog.it        			MSN: michel@ziobuddalabs.it                   

From cristiano a verondini.it  Fri Jun  8 12:43:14 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Fri Jun  8 13:32:49 2007
Subject: [Db] time is NOT now
References: <466918E9.9010305@vezz.it><200706081148.45516.cesare@ngi.it><009901c7a9b2$792aa820$6301a8c0@IdeaFutura.local><200706081230.03358.cesare@ngi.it>
	<00de01c7a9b9$4ff37e30$6301a8c0@IdeaFutura.local>
Message-ID: <00fb01c7a9b9$d25ad300$6301a8c0@IdeaFutura.local>

>>> Il mio portatile attuale si chiama crilin, il vecchio mac pure, il
>>> router a casa kame... e mi fermo qua (a parte il server di sviluppo
>>> in ufficio che si chiama gacchan :-P )
>>
>>    Il mio portatile Neko, quello vecchio Pikachu. La Sun che è stata
>> per anni server principale di facoltà (e che ancora esiste) Lamù.
>> Più tante altre oramai perse ... :)

    Hem, ero convinto di averla mandata in privato ... meno male che non ho 
parlato male di nessuno! :))

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From jonathan a garetjax.info  Fri Jun  8 12:50:12 2007
From: jonathan a garetjax.info (Jonathan Stoppani)
Date: Fri Jun  8 13:34:15 2007
Subject: [Db] time is NOT now
In-Reply-To: <00fb01c7a9b9$d25ad300$6301a8c0@IdeaFutura.local>
References: <466918E9.9010305@vezz.it><200706081148.45516.cesare@ngi.it><009901c7a9b2$792aa820$6301a8c0@IdeaFutura.local><200706081230.03358.cesare@ngi.it>
	<00de01c7a9b9$4ff37e30$6301a8c0@IdeaFutura.local>
	<00fb01c7a9b9$d25ad300$6301a8c0@IdeaFutura.local>
Message-ID: <0E6FF4B6-9328-463D-B72E-52309C735F97@garetjax.info>


On Jun 8, 2007, at 12:43 , Cristiano Verondini wrote:
>    Hem, ero convinto di averla mandata in privato ... meno male che  
> non ho parlato male di nessuno! :))

LOL...

-- 
Best regards,
Jonathan Stoppani ~ http://garetjax.info/blog


From marcello a vezz.it  Fri Jun  8 13:05:12 2007
From: marcello a vezz.it (Marcello Vezzelli)
Date: Fri Jun  8 13:46:56 2007
Subject: [Db] time is NOT now
In-Reply-To: <00fb01c7a9b9$d25ad300$6301a8c0@IdeaFutura.local>
References: <466918E9.9010305@vezz.it><200706081148.45516.cesare@ngi.it><009901c7a9b2$792aa820$6301a8c0@IdeaFutura.local><200706081230.03358.cesare@ngi.it>	<00de01c7a9b9$4ff37e30$6301a8c0@IdeaFutura.local>
	<00fb01c7a9b9$d25ad300$6301a8c0@IdeaFutura.local>
Message-ID: <466937E8.6070101@vezz.it>

Cristiano Verondini ha scritto:
>
>    Hem, ero convinto di averla mandata in privato ... meno male che 
> non ho parlato male di nessuno! :))

Se non altro mi sento meno rincoglionito anch'io :)
E mi ero impegnato così tanto, con un topic citazione dei Moloko :)

it's the friday-effect!

Ciao
Marcello
From cesare a ngi.it  Fri Jun  8 13:29:09 2007
From: cesare a ngi.it (Cesare D'Amico)
Date: Fri Jun  8 14:07:19 2007
Subject: [Db] time is NOT now
In-Reply-To: <4669333C.2030406@ziobudda.net>
References: <466918E9.9010305@vezz.it>
	<006701c7a9af$e90cce50$6301a8c0@IdeaFutura.local>
	<4669333C.2030406@ziobudda.net>
Message-ID: <200706081329.09653.cesare@ngi.it>

Alle 12:45, venerdì 08 giugno 2007, Davide Michel 'ZioBudda' Morelli ha 
scritto:
> "Sembra talco ma non è / serve a darti l'allegria, / se la mangi o la
> respiri, / ti dà subito l'allegria!"

...e poi si chiedono come mai nella nostra generazione di 30enni giri 
tanta cocaina... ci hanno tirato su idolatrandola ;-D

-- 
Cesare D'Amico      |  Gruppo Volta
Area tecnica        |  Web & Mkt Solutions
Tel: 045 21 000 84  |  Via Leida 8 - Verona
Fax: 045 21 000 85  |  http://www.gruppovolta.it
From domenico.lorusso a pleiade.it  Mon Jun 11 11:22:52 2007
From: domenico.lorusso a pleiade.it (Domenico L.)
Date: Mon Jun 11 12:07:55 2007
Subject: [Db] [Mysql] Dubbio architetturale
Message-ID: <466D146C.4000607@pleiade.it>

Ciao all,
    ho un dubbio.

In una tabella ho un campo (valore varchar) che può contenere un numero 
più o meno arbitrario di dati.

In realtà il 90% dei valori non supererà i 50 caratteri ma alcuni 
potrebbero spingersi fino a qualche centinaia (se non migliaia)

Cosa mi suggerite? trasformo "valore" in un text o long-text oppure 
aggiungo un campo (valore-Esteso) che valorizzo solo se i dati da 
inserire sono molti?

Inoltre su "valore" dovranno essere definiti degli indici di ricerca 
(magari anche bitmap) e ovviamente non mi serve  fare una ricerca su un 
testo da 2000 caratteri, o meglio mi potrebbe servire ma non è il caso 
di farci un indice...

ciao

-- 
Domenico L.        	 icq: 645 44 861 - msn: strahd@jumpy.it

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]

From cristiano a verondini.it  Mon Jun 11 11:40:12 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Mon Jun 11 12:29:07 2007
Subject: [Db] [Mysql] Dubbio architetturale
References: <466D146C.4000607@pleiade.it>
Message-ID: <024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>

>> In una tabella ho un campo (valore varchar) che può contenere un
>> numero più o meno arbitrario di dati.
>>
>> In realtà il 90% dei valori non supererà i 50 caratteri ma alcuni
>> potrebbero spingersi fino a qualche centinaia (se non migliaia)
>>
>> Cosa mi suggerite? trasformo "valore" in un text o long-text oppure
>> aggiungo un campo (valore-Esteso) che valorizzo solo se i dati da
>> inserire sono molti?

    Si, direi che l'uso di un campo di 'overflow' sia la soluzione migliore. 
Ti consiglio anche di fare una verifica sulle quantità di dati, perchè 
magari potresti mettere l'overflow in un'altra tabella in relazione 1:1 con 
l'originale e mantenere la prima con record a lunghezza fissa.

        Cris

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From michel a ziobudda.net  Mon Jun 11 12:13:01 2007
From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli)
Date: Mon Jun 11 12:57:35 2007
Subject: [Db] [Mysql] Dubbio architetturale
In-Reply-To: <024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>
References: <466D146C.4000607@pleiade.it>
	<024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>
Message-ID: <466D202D.9040506@ziobudda.net>

Cristiano Verondini ha scritto:
>    Si, direi che l'uso di un campo di 'overflow' sia la soluzione 
> migliore. Ti consiglio anche di fare una verifica sulle quantità di 
> dati, perchè magari potresti mettere l'overflow in un'altra tabella in 
> relazione 1:1 con l'originale e mantenere la prima con record a 
> lunghezza fissa.

Avevo pensato di suggerire la stessa cosa, ma poi mi sono fermato sulla 
questione ricerca. Se devi fare una ricerca all'interno del campo valore 
avendo due tabelle si avranno il doppio delle ricerche.
Giusto ? A questo punto è da considerare "ogni quanto si fanno le 
ricerche" perché se lo si fa spesso è sempre consigliabile una tabella a 
parte ? 

M.

-- 
Michel 'ZioBudda' Morelli                       michel@ziobudda.net
Consulenza sistemistica in ambito OpenSource.
Sviluppo applicazioni web dinamiche (LAMP+Ajax)
Telefono: +39-3939890025 --  Fax: +39-0291390660

http://www.ziobudda.net                         ICQ: 58351764  
http://www.ziobuddalabs.it                      Skype: zio_budda
http://www.ajaxblog.it        			MSN: michel@ziobuddalabs.it                   

From cristiano a verondini.it  Mon Jun 11 12:16:31 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Mon Jun 11 13:06:51 2007
Subject: [Db] [Mysql] Dubbio architetturale
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>
	<466D202D.9040506@ziobudda.net>
Message-ID: <028701c7ac11$9602b5d0$6301a8c0@IdeaFutura.local>


>> Avevo pensato di suggerire la stessa cosa, ma poi mi sono fermato
>> sulla questione ricerca. Se devi fare una ricerca all'interno del
>> campo valore avendo due tabelle si avranno il doppio delle ricerche.
>> Giusto ? A questo punto è da considerare "ogni quanto si fanno le
>> ricerche" perché se lo si fa spesso è sempre consigliabile una
>> tabella a parte ?

    La premessa di valutare i dati era appunto epr capire queste cose. E' 
anche vero che se devi fare delle ricerche su questi dati è più veloce 
averli in una tabella da soli (supponendo che la loro percentuale in 
relazione al numero totale di record sia bassa). E' ovvio che se devi fare 
ricerche su campi di entrambe le tabelle, sei costretto a fare un join, che 
però potrebbe risultare non così pesante se i dati sono correttamente 
indicizzati.

        Cris

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From domenico.lorusso a pleiade.it  Mon Jun 11 12:21:59 2007
From: domenico.lorusso a pleiade.it (Domenico L.)
Date: Mon Jun 11 13:07:00 2007
Subject: [Db] [Mysql] Dubbio architetturale
In-Reply-To: <024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>
References: <466D146C.4000607@pleiade.it>
	<024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>
Message-ID: <466D2247.8030204@pleiade.it>

Cristiano Verondini ha scritto:
>>> In una tabella ho un campo (valore varchar) che può contenere un
>>> numero più o meno arbitrario di dati.
>>>
>>> In realtà il 90% dei valori non supererà i 50 caratteri ma alcuni
>>> potrebbero spingersi fino a qualche centinaia (se non migliaia)
>>>
>>> Cosa mi suggerite? trasformo "valore" in un text o long-text oppure
>>> aggiungo un campo (valore-Esteso) che valorizzo solo se i dati da
>>> inserire sono molti?
>
>    Si, direi che l'uso di un campo di 'overflow' sia la soluzione 
> migliore. Ti consiglio anche di fare una verifica sulle quantità di 
> dati, perchè magari potresti mettere l'overflow in un'altra tabella in 
> relazione 1:1 con l'originale e mantenere la prima con record a 
> lunghezza fissa.
ci stavo pensando ma la chiave della prima tabella è composta da 4 campi 
duplicarla è oneroso...

Dovessi scegliere di adottora la soluzione text il calo di performance 
sarebbe notevole?

-- 
Domenico L.        	 icq: 645 44 861 - msn: strahd@jumpy.it

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]

From michel a ziobudda.net  Mon Jun 11 12:24:51 2007
From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli)
Date: Mon Jun 11 13:10:11 2007
Subject: [Db] [Mysql] Dubbio architetturale
In-Reply-To: <466D2247.8030204@pleiade.it>
References: <466D146C.4000607@pleiade.it>	<024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>
	<466D2247.8030204@pleiade.it>
Message-ID: <466D22F3.2040103@ziobudda.net>

Domenico L. ha scritto:
>>    Si, direi che l'uso di un campo di 'overflow' sia la soluzione 
>> migliore. Ti consiglio anche di fare una verifica sulle quantità di 
>> dati, perchè magari potresti mettere l'overflow in un'altra tabella 
>> in relazione 1:1 con l'originale e mantenere la prima con record a 
>> lunghezza fissa.
> ci stavo pensando ma la chiave della prima tabella è composta da 4 
> campi duplicarla è oneroso...
Metti un nuovo campo NUMERICO che ti fa da relazione tra la prima e la 
seconda tabella.

M.

-- 
Michel 'ZioBudda' Morelli                       michel@ziobudda.net
Consulenza sistemistica in ambito OpenSource.
Sviluppo applicazioni web dinamiche (LAMP+Ajax)
Telefono: +39-3939890025 --  Fax: +39-0291390660

http://www.ziobudda.net                         ICQ: 58351764  
http://www.ziobuddalabs.it                      Skype: zio_budda
http://www.ajaxblog.it        			MSN: michel@ziobuddalabs.it                   

From michel a ziobudda.net  Mon Jun 11 12:27:16 2007
From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli)
Date: Mon Jun 11 13:11:47 2007
Subject: [Db] [Mysql] Dubbio architetturale
In-Reply-To: <028701c7ac11$9602b5d0$6301a8c0@IdeaFutura.local>
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D202D.9040506@ziobudda.net>
	<028701c7ac11$9602b5d0$6301a8c0@IdeaFutura.local>
Message-ID: <466D2384.8070704@ziobudda.net>

Cristiano Verondini ha scritto:
>    La premessa di valutare i dati era appunto epr capire queste cose. 
> E' anche vero che se devi fare delle ricerche su questi dati è più 
> veloce averli in una tabella da soli (supponendo che la loro 
> percentuale in relazione al numero totale di record sia bassa).

Ma non si devono fare delle ricerche solo su questa tabella, ma su 
entrambe perché il 90% dei "valore" è su una ed il 10% è sull'altra.
A questo punto, se le ricerche sul campo "valore" sono "relativamente 
poche rispetto alla totalità" non è consigliabile spostare tutto 
"valore" su una tabella a parte e relazionare le due tabelle tramite una 
colonna "ID" numerica ?

M.

-- 
Michel 'ZioBudda' Morelli                       michel@ziobudda.net
Consulenza sistemistica in ambito OpenSource.
Sviluppo applicazioni web dinamiche (LAMP+Ajax)
Telefono: +39-3939890025 --  Fax: +39-0291390660

http://www.ziobudda.net                         ICQ: 58351764  
http://www.ziobuddalabs.it                      Skype: zio_budda
http://www.ajaxblog.it        			MSN: michel@ziobuddalabs.it                   

From cristiano a verondini.it  Mon Jun 11 12:23:21 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Mon Jun 11 13:12:16 2007
Subject: [Db] [Mysql] Dubbio architetturale
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>
	<466D2247.8030204@pleiade.it>
Message-ID: <02a601c7ac12$8a5c92e0$6301a8c0@IdeaFutura.local>

>> ci stavo pensando ma la chiave della prima tabella è composta da 4
>> campi duplicarla è oneroso...

    Aggiungi un ID autoincrementante ed usa quello per la relazione.

>> Dovessi scegliere di adottora la soluzione text il calo di
>> performance sarebbe notevole?

    Dipende moltissimo dalla struttura e dalla quantità dei dati.

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From cristiano a verondini.it  Mon Jun 11 12:26:08 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Mon Jun 11 13:15:03 2007
Subject: [Db] [Mysql] Dubbio architetturale
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D202D.9040506@ziobudda.net><028701c7ac11$9602b5d0$6301a8c0@IdeaFutura.local>
	<466D2384.8070704@ziobudda.net>
Message-ID: <02b901c7ac12$eeaef260$6301a8c0@IdeaFutura.local>

>> Ma non si devono fare delle ricerche solo su questa tabella, ma su
>> entrambe perché il 90% dei "valore" è su una ed il 10% è sull'altra.

    Questo dipende dall'applicazione. Oltretutto influenza molto il fatto di 
fare ricerche in OR o in AND con i dati sulla seconda tabella. Nel caso 
dell'AND, se i dati nella seconda tabella sono molto inferiori l'approccio è 
decisamente efficiente (sempre che il DB ottimizzi bene la query, altrimenti 
lo puoi forzare con una subquery).

>> A questo punto, se le ricerche sul campo "valore" sono "relativamente
>> poche rispetto alla totalità" non è consigliabile spostare tutto
>> "valore" su una tabella a parte e relazionare le due tabelle tramite
>> una colonna "ID" numerica ?

    Anche questa è una scelta plausibile, ma così facendo perdi il vantaggio 
del record a lunghezza fissa per la maggior parte dei dati.

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From michel a ziobudda.net  Mon Jun 11 12:35:33 2007
From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli)
Date: Mon Jun 11 13:20:04 2007
Subject: [Db] [Mysql] Dubbio architetturale
In-Reply-To: <02b901c7ac12$eeaef260$6301a8c0@IdeaFutura.local>
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D202D.9040506@ziobudda.net><028701c7ac11$9602b5d0$6301a8c0@IdeaFutura.local>	<466D2384.8070704@ziobudda.net>
	<02b901c7ac12$eeaef260$6301a8c0@IdeaFutura.local>
Message-ID: <466D2575.3040109@ziobudda.net>

Cristiano Verondini ha scritto:
>
>    Anche questa è una scelta plausibile, ma così facendo perdi il 
> vantaggio del record a lunghezza fissa per la maggior parte dei dati.

Ma ci sarebbe un indice numerico su una tabella avente solamente 2 
colonne (id e valore) e anche gli spostamenti sarebbero molto piu' 
veloci rispetto ad una tabella con X colonne (dipendentemente dalla 
struttura di quest'ultima).

M.

-- 
Michel 'ZioBudda' Morelli                       michel@ziobudda.net
Consulenza sistemistica in ambito OpenSource.
Sviluppo applicazioni web dinamiche (LAMP+Ajax)
Telefono: +39-3939890025 --  Fax: +39-0291390660

http://www.ziobudda.net                         ICQ: 58351764  
http://www.ziobuddalabs.it                      Skype: zio_budda
http://www.ajaxblog.it        			MSN: michel@ziobuddalabs.it                   

From domenico.lorusso a pleiade.it  Mon Jun 11 12:36:34 2007
From: domenico.lorusso a pleiade.it (Domenico L.)
Date: Mon Jun 11 13:21:56 2007
Subject: [Db] [Mysql] Dubbio architetturale
In-Reply-To: <02a601c7ac12$8a5c92e0$6301a8c0@IdeaFutura.local>
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D2247.8030204@pleiade.it>
	<02a601c7ac12$8a5c92e0$6301a8c0@IdeaFutura.local>
Message-ID: <466D25B2.9050509@pleiade.it>

Cristiano Verondini ha scritto:
>>> ci stavo pensando ma la chiave della prima tabella è composta da 4
>>> campi duplicarla è oneroso...
>
>    Aggiungi un ID autoincrementante ed usa quello per la relazione.
sì lo so ma non mi piace e aggiungo complessità procedurale.. cmq...
>
>>> Dovessi scegliere di adottora la soluzione text il calo di
>>> performance sarebbe notevole?
>
>    Dipende moltissimo dalla struttura e dalla quantità dei dati.
Spiego meglio la domanda, posto di utilizzare un medium-blob per 
memorizzare dati che hanno una lunghezza, normalmente tra 0 e 10 con 
qualche punta sui 50 e rarissimi casi con centinaia o miliaia, Mysql ha 
qualche soluzione ad hoc per affrontare la situazione?

Le ricerche in realtà si faranno al 99% in questo modo:
- Ricerca per uno o più campi chiave (messi in PK) e like su valore

Cosa che mi porterebbe a pensare di on dover mettere indici su  valore.. 
però non si sa mai...

-- 
Domenico L.        	 icq: 645 44 861 - msn: strahd@jumpy.it

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]

From cristiano a verondini.it  Mon Jun 11 12:34:58 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Mon Jun 11 13:23:55 2007
Subject: [Db] [Mysql] Dubbio architetturale
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D202D.9040506@ziobudda.net><028701c7ac11$9602b5d0$6301a8c0@IdeaFutura.local>	<466D2384.8070704@ziobudda.net><02b901c7ac12$eeaef260$6301a8c0@IdeaFutura.local>
	<466D2575.3040109@ziobudda.net>
Message-ID: <02da01c7ac14$2a562300$6301a8c0@IdeaFutura.local>

>>>    Anche questa è una scelta plausibile, ma così facendo perdi il
>>> vantaggio del record a lunghezza fissa per la maggior parte dei
>>> dati.
>>
>> Ma ci sarebbe un indice numerico su una tabella avente solamente 2
>> colonne (id e valore) e anche gli spostamenti sarebbero molto piu'
>> veloci rispetto ad una tabella con X colonne (dipendentemente dalla
>> struttura di quest'ultima).

    Si, ma la ricerca non la fai su un indice numerico, ed il fatto che i 
campi siano TEXT rende le ricerche molto più pesanti, quindi è meglio tenere 
la tabella il più piccolo possibile.

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From cristiano a verondini.it  Mon Jun 11 12:35:52 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Mon Jun 11 13:24:48 2007
Subject: [Db] [Mysql] Dubbio architetturale
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D2247.8030204@pleiade.it><02a601c7ac12$8a5c92e0$6301a8c0@IdeaFutura.local>
	<466D25B2.9050509@pleiade.it>
Message-ID: <02df01c7ac14$4a518b90$6301a8c0@IdeaFutura.local>

>>>    Dipende moltissimo dalla struttura e dalla quantità dei dati.
>> Spiego meglio la domanda, posto di utilizzare un medium-blob per
>> memorizzare dati che hanno una lunghezza, normalmente tra 0 e 10 con
>> qualche punta sui 50 e rarissimi casi con centinaia o miliaia, Mysql
>> ha qualche soluzione ad hoc per affrontare la situazione?

    Indici full-text!

>> Le ricerche in realtà si faranno al 99% in questo modo:
>> - Ricerca per uno o più campi chiave (messi in PK) e like su valore

    Il LIKE è mortale, costringe ad un full table scan ...

>> Cosa che mi porterebbe a pensare di on dover mettere indici su
>> valore.. però non si sa mai...

    Vedi sopra! :)

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From domenico.lorusso a pleiade.it  Mon Jun 11 12:53:52 2007
From: domenico.lorusso a pleiade.it (Domenico L.)
Date: Mon Jun 11 13:38:30 2007
Subject: [Db] [Mysql] Dubbio architetturale
In-Reply-To: <02df01c7ac14$4a518b90$6301a8c0@IdeaFutura.local>
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D2247.8030204@pleiade.it><02a601c7ac12$8a5c92e0$6301a8c0@IdeaFutura.local>	<466D25B2.9050509@pleiade.it>
	<02df01c7ac14$4a518b90$6301a8c0@IdeaFutura.local>
Message-ID: <466D29C0.4030704@pleiade.it>

Cristiano Verondini ha scritto:
>>> Le ricerche in realtà si faranno al 99% in questo modo:
>>> - Ricerca per uno o più campi chiave (messi in PK) e like su valore
>
>    Il LIKE è mortale, costringe ad un full table scan ...
stai scherzando? stiamo parlando di un dbms o di un bidone di immondizia???

*Deve* prima filtrare sui campi chiave e poi effettuare un like, per 
forza... altrimenti tanto vale tornare ad utilizzare i file!!!

Hai un link con la fonte di questa notizia... non ci voglio credere...

anzi ti dirò di più mi aspetterei che
nome like 'Ciao%'
se su Ciao è definito un indice mi faccia un accesso via indice...


-- 
Domenico L.        	 icq: 645 44 861 - msn: strahd@jumpy.it

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]

From cristiano a verondini.it  Mon Jun 11 12:53:35 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Mon Jun 11 13:42:37 2007
Subject: [Db] [Mysql] Dubbio architetturale
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D2247.8030204@pleiade.it><02a601c7ac12$8a5c92e0$6301a8c0@IdeaFutura.local>	<466D25B2.9050509@pleiade.it><02df01c7ac14$4a518b90$6301a8c0@IdeaFutura.local>
	<466D29C0.4030704@pleiade.it>
Message-ID: <030a01c7ac16$c3bab680$6301a8c0@IdeaFutura.local>

>> *Deve* prima filtrare sui campi chiave e poi effettuare un like, per
>> forza... altrimenti tanto vale tornare ad utilizzare i file!!!

    Intendevo se è l'unico criterio di ricerca! :)

>> anzi ti dirò di più mi aspetterei che
>> nome like 'Ciao%'
>> se su Ciao è definito un indice mi faccia un accesso via indice...

    Dipende dal tipo di indice. Alcuni lo permettono, altri no. Naturalmente 
poi sta al DBMS usare questa caratteristica.

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From domenico.lorusso a pleiade.it  Mon Jun 11 13:05:56 2007
From: domenico.lorusso a pleiade.it (Domenico L.)
Date: Mon Jun 11 13:50:37 2007
Subject: [Db] [Mysql] Dubbio architetturale
In-Reply-To: <030a01c7ac16$c3bab680$6301a8c0@IdeaFutura.local>
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D2247.8030204@pleiade.it><02a601c7ac12$8a5c92e0$6301a8c0@IdeaFutura.local>	<466D25B2.9050509@pleiade.it><02df01c7ac14$4a518b90$6301a8c0@IdeaFutura.local>	<466D29C0.4030704@pleiade.it>
	<030a01c7ac16$c3bab680$6301a8c0@IdeaFutura.local>
Message-ID: <466D2C94.5040501@pleiade.it>

Cristiano Verondini ha scritto:
>>> *Deve* prima filtrare sui campi chiave e poi effettuare un like, per
>>> forza... altrimenti tanto vale tornare ad utilizzare i file!!!
>
>    Intendevo se è l'unico criterio di ricerca! :)
accidenti, prof! mi hai fatto prendere un colpo!
>>> nome like 'Ciao%'
>>> se su nome è definito un indice mi faccia un accesso via indice...
> anzi ti dirò di più mi aspetterei che
>
>    Dipende dal tipo di indice. Alcuni lo permettono, altri no. 
> Naturalmente poi sta al DBMS usare questa caratteristica.
immagino che mysql sia per il no vero? in che senso dal tipo di indice?

Mi spiego uno dei campi chiave è appunto "nome" che è una stringa. il 
suo valore è definito da un dizionario e da regole.
Tra queste regole vi è quella di iniziare con una determinata parola per 
indicare il contesto di questo record, esempio:

anagrafica@cognome

i contesti possono essere più di uno:

anagrafica@nascita@Data

mi piacerebbe poter fare filtri del tipo:
anagrafica@%
o anagrafica@nascita@%

e mi aspettavo usassero l'indice ...

Naturalmente potrei spostare questo campo in una tabella dizionario, 
metterci un fulltext su questa tabella utilizzare un campo numerico 
nella tabella dati e fare una join... solo che per una serie di 
motivazioni  (su tutte la flessibilità) mi è poco conveniente....

-- 
Domenico L.        	 icq: 645 44 861 - msn: strahd@jumpy.it

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]

From cristiano a verondini.it  Mon Jun 11 13:05:32 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Mon Jun 11 13:54:28 2007
Subject: [Db] [Mysql] Dubbio architetturale
References: <466D146C.4000607@pleiade.it><024d01c7ac0c$8385fd90$6301a8c0@IdeaFutura.local>	<466D2247.8030204@pleiade.it><02a601c7ac12$8a5c92e0$6301a8c0@IdeaFutura.local>	<466D25B2.9050509@pleiade.it><02df01c7ac14$4a518b90$6301a8c0@IdeaFutura.local>	<466D29C0.4030704@pleiade.it><030a01c7ac16$c3bab680$6301a8c0@IdeaFutura.local>
	<466D2C94.5040501@pleiade.it>
Message-ID: <032901c7ac18$6f813600$6301a8c0@IdeaFutura.local>

>>>>> nome like 'Ciao%'
>>>>> se su nome è definito un indice mi faccia un accesso via indice...
>>> anzi ti dirò di più mi aspetterei che

>>>    Dipende dal tipo di indice. Alcuni lo permettono, altri no.
>>> Naturalmente poi sta al DBMS usare questa caratteristica.

>> immagino che mysql sia per il no vero? in che senso dal tipo di
>> indice?

    Ad esempio se il DBMS usa BTree, una cosa del genere dovrebbe essere 
possibile. Non credo però sia possibile se il BTree usa la 'tail 
compression' ...

    mysql dovrebbe usare questa caratteristica quando ricerchi per valori 
parziali della chiave dell'indice.

>> Mi spiego uno dei campi chiave è appunto "nome" che è una stringa. il
>> suo valore è definito da un dizionario e da regole.
>> Tra queste regole vi è quella di iniziare con una determinata parola
>> per indicare il contesto di questo record, esempio:
>>
>> anagrafica@cognome
>>
>> i contesti possono essere più di uno:
>>
>> anagrafica@nascita@Data
>>
>> mi piacerebbe poter fare filtri del tipo:
>> anagrafica@%
>> o anagrafica@nascita@%
>>
>> e mi aspettavo usassero l'indice ...

    Dovrebbero, ma una EXPLAIN ti darà questa certezza.

>> Naturalmente potrei spostare questo campo in una tabella dizionario,
>> metterci un fulltext su questa tabella utilizzare un campo numerico
>> nella tabella dati e fare una join... solo che per una serie di
>> motivazioni  (su tutte la flessibilità) mi è poco conveniente....

    Bhe, questa era l'idea iniziale ... :)

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From giuseppe a arsnet.it  Wed Jun 13 18:43:53 2007
From: giuseppe a arsnet.it (giuseppe@arsnet.it)
Date: Wed Jun 13 19:50:29 2007
Subject: [Db] mysql spostare record tra due tabelle
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARoa1UrI2y0igDT5S4dIF+sKAAAAQAAAAur6/VWCilkqlkwChjMNmIAEAAAAA@arsnet.it>

Salve a tutti, sarà la stanchezza ma non riesco a trovare sul manuale di
mysql se è possibile spostare record tra una tabella ed un’altra.

Mi spiego meglio:

io ho una tabella ordini ed una tabella storico_ordini, ho necessità tutti i
giorni di copiare tutti i record della tabella ordini ed inserirli nella
tabella storico_ordini dopodichè devo svuotare la tabella ordini.



La prima idea era di dividere il lavoro in due query separate la prima che
copia i record nello storico:

“INSERT INTO storico_ordini (ordine_id,data,id_anacf,numero)
SELECT ordine_id,data,id_anacf,numero
FROM ordini”

E la seconda che svuota la tabella ordini:

“truncate teste_ordini”

Ma preferirei fare tutto con un’unica query per evitare di dover fare troppi
controlli Es. se un record non viene copiato nella tabella storico per
qualsivoglia motivo e io ho svuotato la tabella ordini ho perso quel record.


Spero di essere stato abbastanza chiaro, se fosse altrimenti scusatemi (è
dalle 05:30 che soo davanti al monitor, la testa non c’è più tanto!!!)

Grazie!!

Beppe





  _____  

avast! Antivirus <http://www.avast.com> : In partenza messaggio pulito. 


Virus Database (VPS): 000748-5, 13/06/2007
Controllato il: 13/06/2007 18.43.53
avast! - copyright (c) 1988-2007 ALWIL Software.



From cristiano a verondini.it  Wed Jun 13 19:09:42 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Wed Jun 13 19:59:08 2007
Subject: [Db] mysql spostare record tra due tabelle
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARoa1UrI2y0igDT5S4dIF+sKAAAAQAAAAur6/VWCilkqlkwChjMNmIAEAAAAA@arsnet.it>
Message-ID: <01f601c7addd$a3b1baa0$6301a8c0@IdeaFutura.local>

> La prima idea era di dividere il lavoro in due query separate la
> prima che copia i record nello storico:
>
> "INSERT INTO storico_ordini (ordine_id,data,id_anacf,numero)
> SELECT ordine_id,data,id_anacf,numero
> FROM ordini"
>
> E la seconda che svuota la tabella ordini:
>
> "truncate teste_ordini"
>
> Ma preferirei fare tutto con un'unica query per evitare di dover fare
> troppi controlli Es. se un record non viene copiato nella tabella
> storico per qualsivoglia motivo e io ho svuotato la tabella ordini ho
> perso quel record.

    Purtroppo, AFAIK, questo è l'unico metodo. Aggiungerei un LOCK delle 
tabelle prima delle operazioni per evitare che mentre stai facendo la copia 
vengano inseriti altri record. Se non ci sono errori, la procedura non ha 
problemi. Se ci sono errori sarebbe meglio avere un motore DB col rollback.

    Se non hai troppi record ed hai paura di creare casini, puoi sempre 
procedere record per record. Il DB probabilmente ti ucciderebbe, ma a 
livello applicativo hai sotto controllo l'intero processo.

        Cris

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From giuseppe a arsnet.it  Wed Jun 13 19:31:42 2007
From: giuseppe a arsnet.it (giuseppe@arsnet.it)
Date: Wed Jun 13 20:17:58 2007
Subject: R: [Db] mysql spostare record tra due tabelle
In-Reply-To: <01f601c7addd$a3b1baa0$6301a8c0@IdeaFutura.local>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARoa1UrI2y0igDT5S4dIF+sKAAAAQAAAAbzTaSXobJEOUhcNbJmdESwEAAAAA@arsnet.it>

Cristiano Verondini wrote:

>Purtroppo, AFAIK, questo è l'unico metodo. Aggiungerei un LOCK delle
>tabelle prima delle operazioni per evitare che mentre stai facendo la copia
>vengano inseriti altri record. Se non ci sono errori, la procedura non ha
>problemi. Se ci sono errori sarebbe meglio avere un motore DB col rollback.

  Ho trovato una mezza soluzione:

“INSERT INTO storico_ordini (ordine_id,data,id_anacf,numero)
SELECT ordine_id,data,id_anacf,numero
FROM ordini”
"delete from ordini where ordine_id in (select ordine_id from storico
_ordini) "


continuo ad eseguire due query separate ma non mi devo preoccupare se un
record non viene inserito nella tabella dello storico.

Per quel che riguarda il lock non è necessario in quanto la procedura viene
lanciata dall'amministratore di sistema quando tutti gli utenti sono
scollegati.




  _____  

avast! Antivirus <http://www.avast.com> : In partenza messaggio pulito. 


Virus Database (VPS): 000748-5, 13/06/2007
Controllato il: 13/06/2007 19.31.41
avast! - copyright (c) 1988-2007 ALWIL Software.



From indorato a emme-i.org  Thu Jun 14 01:17:12 2007
From: indorato a emme-i.org (Matteo Indorato)
Date: Thu Jun 14 02:13:02 2007
Subject: R: [Db] mysql spostare record tra due tabelle
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARoa1UrI2y0igDT5S4dIF+sKAAAAQAAAAbzTaSXobJEOUhcNbJmdESwEAAAAA@arsnet.it>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARoa1UrI2y0igDT5S4dIF+sKAAAAQAAAAbzTaSXobJEOUhcNbJmdESwEAAAAA@arsnet.it>
Message-ID: <200706140117.12452.indorato@emme-i.org>

Ciao piuttosto che una delete from where in (...)
ti conviene mettere in join le due tabelle e fare la delete
Dovresti avere prestazioni migliori, indici permettendo.

Matteo

Alle 19:31, mercoledì 13 giugno 2007, giuseppe@arsnet.it ha scritto:
> Cristiano Verondini wrote:
> >Purtroppo, AFAIK, questo è l'unico metodo. Aggiungerei un LOCK delle
> >tabelle prima delle operazioni per evitare che mentre stai facendo la
> > copia vengano inseriti altri record. Se non ci sono errori, la procedura
> > non ha problemi. Se ci sono errori sarebbe meglio avere un motore DB col
> > rollback.
>
>   Ho trovato una mezza soluzione:
>
> “INSERT INTO storico_ordini (ordine_id,data,id_anacf,numero)
> SELECT ordine_id,data,id_anacf,numero
> FROM ordini”
> "delete from ordini where ordine_id in (select ordine_id from storico
> _ordini) "
>
>
> continuo ad eseguire due query separate ma non mi devo preoccupare se un
> record non viene inserito nella tabella dello storico.
>
> Per quel che riguarda il lock non è necessario in quanto la procedura viene
> lanciata dall'amministratore di sistema quando tutti gli utenti sono
> scollegati.
>
>
>
>
>   _____
>
> avast! Antivirus <http://www.avast.com> : In partenza messaggio pulito.
>
>
> Virus Database (VPS): 000748-5, 13/06/2007
> Controllato il: 13/06/2007 19.31.41
> avast! - copyright (c) 1988-2007 ALWIL Software.
>
>
>
> _______________________________________________
> Db mailing list
> Db@lists.ziobudda.net
> http://lists.ziobudda.net/mailman/listinfo/db

-- 
Non dico tutto quel che penso...
... Ma tutto quel che dico lo penso ...
--
From domenico.lorusso a pleiade.it  Thu Jun 14 09:03:53 2007
From: domenico.lorusso a pleiade.it (Domenico L.)
Date: Thu Jun 14 09:48:27 2007
Subject: R: [Db] mysql spostare record tra due tabelle
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARoa1UrI2y0igDT5S4dIF+sKAAAAQAAAAbzTaSXobJEOUhcNbJmdESwEAAAAA@arsnet.it>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARoa1UrI2y0igDT5S4dIF+sKAAAAQAAAAbzTaSXobJEOUhcNbJmdESwEAAAAA@arsnet.it>
Message-ID: <4670E859.3070606@pleiade.it>

giuseppe@arsnet.it ha scritto:
> Cristiano Verondini wrote:
>
>   
>> Purtroppo, AFAIK, questo è l'unico metodo. Aggiungerei un LOCK delle
>> tabelle prima delle operazioni per evitare che mentre stai facendo la copia
>> vengano inseriti altri record. Se non ci sono errori, la procedura non ha
>> problemi. Se ci sono errori sarebbe meglio avere un motore DB col rollback.
>>     
>
>   Ho trovato una mezza soluzione:
>
> ?INSERT INTO storico_ordini (ordine_id,data,id_anacf,numero)
> SELECT ordine_id,data,id_anacf,numero
> FROM ordini?
> "delete from ordini where ordine_id in (select ordine_id from storico
> _ordini) "
>   
Non ho le specifiche di mysql ma temo ch questa soluzione alla lunga ti 
darà problemi perché la delete non rimuove lo spazio occupato mentre la 
truncate sì.

La prima soluzione da te proposta è quella corretta, non ci possono 
essere errori in una insert....select
è un'istruzione atomica e come tale o va tutta a buon fine o non ci va.

I punti su cui devi prestare attenzione sono:
- Mettere in transazione
- Lock di tabella per evitare inserimenti nel mentre stai storicizzando 
i dati
- Eventuli trigger sulla tabella di storico.

Se poi vuoi (in pseudo codice):
lock
begin transaction

select .... insert

select p.id
from produzione p left join storico s on (p.id=s.id)
where s.id is null

#se questa query torna qualcosa hai avuto un problema!

end transaction
truncate produzione
unlock



ciao

-- 
Domenico L.        	 icq: 645 44 861 - msn: strahd@jumpy.it

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]


From arete a gerardodiiorio.com  Tue Jun 26 18:30:47 2007
From: arete a gerardodiiorio.com (Gerardo Di Iorio)
Date: Tue Jun 26 19:09:15 2007
Subject: [Db] query ricorsiva
Message-ID: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>

Ciao,

ho un problema con uan query.
Ho una tabella ricorsiva con una struttura id , id_parent

es.
id            id_parent
1                NULL         (Nodo root)
2                 1           (figlio di root)
3                 2
...              ....

4                NULL         altro nodo di root
..


Partendo da un nodo foglia, deve selezionare gli id di tutti i padri.
esempio
assumendo id=3 nodo foglia mi deve restituire id=2 e id=1, naturalmente
posso avere un numero di figli indefinito.
Come posso scrivere questa query in sql?

Ciao e grazie in anticipo
From cristiano a verondini.it  Tue Jun 26 19:33:03 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Tue Jun 26 20:22:05 2007
Subject: [Db] query ricorsiva
In-Reply-To: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>
References: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>
Message-ID: <542E997D-F92F-46F9-B447-73730FAF90C1@verondini.it>


On 26/giu/07, at 18:30, Gerardo Di Iorio wrote:

> Partendo da un nodo foglia, deve selezionare gli id di tutti i padri.
> esempio
> assumendo id=3 nodo foglia mi deve restituire id=2 e id=1,  
> naturalmente
> posso avere un numero di figli indefinito.
> Come posso scrivere questa query in sql?

	AFAIK puoi farlo solo a livello applicativo o con una stored  
procedure. Esistono però metodi più efficienti per la memorizzazione  
su un DB relazionale degli alberi.

		Cris

-- 
Cristiano Verondini
http://www.verondini.it  ---  [ICQ 114 190]





From parided a gmail.com  Wed Jun 27 08:34:37 2007
From: parided a gmail.com (Paride Desimone)
Date: Wed Jun 27 09:26:53 2007
Subject: [Db] Aiuto postgresql su debian
In-Reply-To: <542E997D-F92F-46F9-B447-73730FAF90C1@verondini.it>
References: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>
	<542E997D-F92F-46F9-B447-73730FAF90C1@verondini.it>
Message-ID: <1182926077.27312.10.camel@it.ferramentazizzi.it>

Salve a tutti,
premetto che sono nuovo a questa ml.
Sto installando igsuite (www.igsuite.org) e vorrei mettere il supporto a
postgresql.
Mi servirebbe sapere velocemente come impostare l'utene master e la
password ed aggiungere gli altri utenti.
Ho provato a guardare velocemente sul sito di postgresql, ma non sono
riuscito a trovare le infrmazioni che mi servono.
Esiste un manuale in italiano su postgresql? L'inglese va bene, ma per
argomenti tecnici e' indubbiamente piu' facile la lingua madre :-)
Qualcuno puo' aiutarmi?

Paride

From cesare a ngi.it  Wed Jun 27 09:45:30 2007
From: cesare a ngi.it (Cesare D'Amico)
Date: Wed Jun 27 10:35:18 2007
Subject: [Db] query ricorsiva
In-Reply-To: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>
References: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>
Message-ID: <200706270945.30779.cesare@ngi.it>

Alle 18:30, martedì 26 giugno 2007, Gerardo Di Iorio ha scritto:
> Ho una tabella ricorsiva con una struttura id , id_parent

Googla "sql nested sets" oppure "celko sql trees" (o qcosa di simile). 
Joe Celko è tuo amico ;)

Ciaps
     ce

-- 
Cesare D'Amico      |  Gruppo Volta
Area tecnica        |  Web & Mkt Solutions
Tel: 045 21 000 84  |  Via Leida 8 - Verona
Fax: 045 21 000 85  |  http://www.gruppovolta.it
From franco a inpe.unipi.it  Wed Jun 27 10:14:55 2007
From: franco a inpe.unipi.it (Francesco F)
Date: Wed Jun 27 11:15:54 2007
Subject: [Db] query ricorsiva
In-Reply-To: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>
References: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>
Message-ID: <46821C7F.70407@inpe.unipi.it>

On 26/06/2007 18.30, Gerardo Di Iorio wrote:
> Come posso scrivere questa query in sql?
> 

Guarda questo link: vengono confrontati due diverse implementazioni ad 
albero, con relativo codice in php (se non ricordo male, per utilizzare 
solo l'sql bisogna bisogna conoscere a priori la profondità dell'albero)
http://www.sitepoint.com/article/hierarchical-data-database

Interessante la nota di Cristiano, attraverso store procedure: qualche link?

	Francesco
From gianiaz a gianiaz.net  Wed Jun 27 11:34:37 2007
From: gianiaz a gianiaz.net (Giovanni Battista Lenoci)
Date: Wed Jun 27 12:22:10 2007
Subject: [Db] query ricorsiva
In-Reply-To: <542E997D-F92F-46F9-B447-73730FAF90C1@verondini.it>
References: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>
	<542E997D-F92F-46F9-B447-73730FAF90C1@verondini.it>
Message-ID: <46822F2D.6070905@gianiaz.net>

Cristiano Verondini ha scritto:
>     AFAIK puoi farlo solo a livello applicativo o con una stored 
> procedure. Esistono però metodi più efficienti per la memorizzazione 
> su un DB relazionale degli alberi.
>
>         Cris
>
Hai qualche link?

Mi sono letto quello passato da Francesco F, ma a parte il primo metodo 
che è quello classico, il secondo mi sembra macchinoso e inutile, perchè 
se devo conoscere a priori il totale dei nodi perdo la gran parte delle 
funzionalità dell'avere un albero su db.

Ciao e grazie


-- 
gianiaz.net
di Giovanni Battista Lenoci 
P.le Bertacchi 66 
23100 Sondrio
cell. +39.392.7096936
cell. +39.347.7196482

From cristiano a verondini.it  Wed Jun 27 11:45:04 2007
From: cristiano a verondini.it (Cristiano Verondini)
Date: Wed Jun 27 12:37:28 2007
Subject: [Db] query ricorsiva
References: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com><542E997D-F92F-46F9-B447-73730FAF90C1@verondini.it>
	<46822F2D.6070905@gianiaz.net>
Message-ID: <015701c7b89f$d8240aa0$6301a8c0@IdeaFutura.local>

>>     AFAIK puoi farlo solo a livello applicativo o con una stored
>> procedure. Esistono però metodi più efficienti per la memorizzazione
>> su un DB relazionale degli alberi.

> Hai qualche link?

    La rete è piena di materiale. Questo può essere un buon punto di 
partenza: 
http://www.evolt.org/article/Four_ways_to_work_with_hierarchical_data/17/4047/index.html%5C%22

    Ovviamente è possibile integrare le soluzioni proposte con stored 
procedures (per rispondere all'altra domanda).

        Cris

-- 
Cristiano Verondini
http://www.verondini.it  ---   [ICQ: 114 190] 

From arete a gerardodiiorio.com  Wed Jun 27 18:48:28 2007
From: arete a gerardodiiorio.com (Gerardo Di Iorio)
Date: Wed Jun 27 19:27:06 2007
Subject: [Db] query ricorsiva
In-Reply-To: <015701c7b89f$d8240aa0$6301a8c0@IdeaFutura.local>
Message-ID: <GJmOb2LE.1182962908.4800980.arete@gerardodiiorio.com>

In data 27/6/2007, "Cristiano Verondini" <cristiano@verondini.it> ha
scritto:

>>>     AFAIK puoi farlo solo a livello applicativo o con una stored
>>> procedure. Esistono però metodi più efficienti per la memorizzazione
>>> su un DB relazionale degli alberi.
>
>> Hai qualche link?
>
>    La rete è piena di materiale. Questo può essere un buon punto di
>partenza:
>http://www.evolt.org/article/Four_ways_to_work_with_hierarchical_data/17/4047/index.html%5C%22
>
>    Ovviamente è possibile integrare le soluzioni proposte con stored
>procedures (per rispondere all'altra domanda).
>
>        Cris
>

Ti faccio una domanda diretta, tu come avresti fatto?
Perche non ne discutiamo un po' in modo da conoscere i vari punti di
vista?

ciao

>--
>Cristiano Verondini
>http://www.verondini.it  ---   [ICQ: 114 190]
>
>_______________________________________________
>Db mailing list
>Db@lists.ziobudda.net
>http://lists.ziobudda.net/mailman/listinfo/db
From parided a gmail.com  Thu Jun 28 18:09:29 2007
From: parided a gmail.com (Paride Desimone)
Date: Thu Jun 28 19:02:04 2007
Subject: [Db] Aiuto postgresql su debian
In-Reply-To: <542E997D-F92F-46F9-B447-73730FAF90C1@verondini.it>
References: <AwsqT1UJ.1182875447.2342890.arete@gerardodiiorio.com>
	<542E997D-F92F-46F9-B447-73730FAF90C1@verondini.it>
Message-ID: <1183046969.25786.6.camel@it.ferramentazizzi.it>

Salve a tutti,
premetto che sono nuovo a questa ml.
Sto installando igsuite (www.igsuite.org) e vorrei mettere il supporto a
postgresql.
Mi servirebbe sapere velocemente come impostare l'utene master e la
password ed aggiungere gli altri utenti.
Ho provato a guardare velocemente sul sito di postgresql, ma non sono
riuscito a trovare le infrmazioni che mi servono.
Esiste un manuale in italiano su postgresql? L'inglese va bene, ma per
argomenti tecnici e' indubbiamente piu' facile la lingua madre :-)
Qualcuno puo' aiutarmi?

Paride