Forum: Italian Ruby user group memorizzare hash in un campo di una tabella.

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Msan M. (Guest)
on 2009-03-04 11:07
(Received via mailing list)
Mi spiego:
Nel form in un campo di inupt l'utente inserisce qualcosa tipo:
2007[1.456,000] 2006[5.343,55] 2008[2.3445.655].
Sono dei dati adatti ad essere inseriti in un hash.
Devo memorizzare questi dati in una tabella ma ovviamente non esiste
il campo tipo hash.
Posso solamente memorizzarli come stringa e poi trovare il modo di
trattarli come hash da codice?
Pietro G. (Guest)
on 2009-03-04 11:23
(Received via mailing list)
Il 4 marzo 2009 10.06, Mauro <removed_email_address@domain.invalid> ha scritto:
> Mi spiego:
> Nel form in un campo di inupt l'utente inserisce qualcosa tipo:
> 2007[1.456,000] 2006[5.343,55] 2008[2.3445.655].
> Sono dei dati adatti ad essere inseriti in un hash.
> Devo memorizzare questi dati in una tabella ma ovviamente non esiste
> il campo tipo hash.
> Posso solamente memorizzarli come stringa e poi trovare il modo di
> trattarli come hash da codice?

dipende: a te serve un hash per ogni riga?

potresti effettivamente memorizzare la stringa e poi ogni volta che
serve ricreare l'hash, ma:

* innanzitutto, l'hash lo devi fare "a mano", cioè, senza eseguire
codice dell'utente, perché non si sa mai;

* non potresti facilmente fare ricerche: ad esempio, non avresti modo
di trovare il record che ha il valore più alto per la chiave 2007.

* il processo di popolare ogni volta l'hash potrebbe non essere
velocissimo, specie se lo fai su tanti record in una volta.


do per scontato che le chiavi dell'hash non siano sempre uguali,
perché se invece lo fossero, la soluzione sarebbe banale: aggiungere
una colonna per ogni chiave dell'hash.

ci sarebbe un'altra possibilità: potresti creare una tabella di coppie
chiave-valore, tipo:

create_table "key_value" do |t|
  t.integer key
  t.float value
  t.integer altratabella_id
end

così ogni record della tabella principale avrebbe diverse coppie
chiave-valore.

così puoi fare ricerche, ordinamenti etc., e il maggior carico
richiesto per gestire la relazione uno a molti sarebbe, credo,
abbondantemente minore del carico di fare ogni volta il parsing della
stringa.


poi, tutto dipende dall'applicazione, da cosa devi fare con questi
dati e quanto spesso.

pietro
Msan M. (Guest)
on 2009-03-04 11:32
(Received via mailing list)
2009/3/4 Pietro G. <removed_email_address@domain.invalid>:
> dipende: a te serve un hash per ogni riga?
Si ma non e' che mi serve avere l'hash, pensavo di trasfomare la
stringa in hash per una migliore gestione ad esempio nel presentare i
dati.

> * il processo di popolare ogni volta l'hash potrebbe non essere
> velocissimo, specie se lo fai su tanti record in una volta.
>
>
> do per scontato che le chiavi dell'hash non siano sempre uguali,
> perché se invece lo fossero, la soluzione sarebbe banale: aggiungere
> una colonna per ogni chiave dell'hash.
>

in ogni record le chiavi sono diverse cioe' ogni record ha come chiavi
2006 ,2007, 2008.
L'anno prossimo le chiavi per i nuovi record inseriti potrebbero
essere 2007, 2008, 2009.
Pietro G. (Guest)
on 2009-03-04 12:10
(Received via mailing list)
2009/3/4 Mauro <removed_email_address@domain.invalid>:
> 2009/3/4 Pietro G. <removed_email_address@domain.invalid>:
>> dipende: a te serve un hash per ogni riga?
>
> Si ma non e' che mi serve avere l'hash, pensavo di trasfomare la
> stringa in hash per una migliore gestione ad esempio nel presentare i
> dati.

beh, se con quei valori non ci devi fare assolutamente niente a parte
mostrarli, potresti anche lasciarli come stringa...

> in ogni record le chiavi sono diverse cioe' ogni record ha come chiavi
> 2006 ,2007, 2008.
> L'anno prossimo le chiavi per i nuovi record inseriti potrebbero
> essere 2007, 2008, 2009.

scusa, e se facessi tre campi, tipo tre_anni_prima, due_anni_prima,
un_anno_prima?

pietro
Msan M. (Guest)
on 2009-03-04 16:50
(Received via mailing list)
2009/3/4 Pietro G. <removed_email_address@domain.invalid>:
>> in ogni record le chiavi sono diverse cioe' ogni record ha come chiavi
>> 2006 ,2007, 2008.
>> L'anno prossimo le chiavi per i nuovi record inseriti potrebbero
>> essere 2007, 2008, 2009.
>
> scusa, e se facessi tre campi, tipo tre_anni_prima, due_anni_prima,
> un_anno_prima?

Ci avevo pensato e forse sarebbe stato meglio fare cosi' in termini di
normalizzazione della tabella, ma va bene anche cosi' com'e' in fondo
se i dati sono inseriti in maniera coerente posso gestirli come
voglio.
Alessandro S. (Guest)
on 2009-03-05 16:49
Se formatti bene la tua hash =>> {[nome] => [valore], .... }
puoi usare YAML

Msan M. wrote:
> 2009/3/4 Pietro G. <removed_email_address@domain.invalid>:
>>> in ogni record le chiavi sono diverse cioe' ogni record ha come chiavi
>>> 2006 ,2007, 2008.
>>> L'anno prossimo le chiavi per i nuovi record inseriti potrebbero
>>> essere 2007, 2008, 2009.
>>
>> scusa, e se facessi tre campi, tipo tre_anni_prima, due_anni_prima,
>> un_anno_prima?
>
> Ci avevo pensato e forse sarebbe stato meglio fare cosi' in termini di
> normalizzazione della tabella, ma va bene anche cosi' com'e' in fondo
> se i dati sono inseriti in maniera coerente posso gestirli come
> voglio.
Luca de Marinis (Guest)
on 2009-03-05 18:36
(Received via mailing list)
Alessandro S. wrote:
> Se formatti bene la tua hash =>> {[nome] => [valore], .... }
> puoi usare YAML
>
>
Oppure usare il metodo serialize di ActiveRecord::Base

class User < ActiveRecord::Base
    serialize :preferences
end

Il meccanismo e' spiegato nella documentazione di ActiveRecord::Base
stessa.
Il vantaggio e' che la (de)serializzazione la fa lui.

Ciao


--

________________________________________________________________________

*Luca S.G. de Marinis
*/Senior developer/**

 Roma - tel.+39.0658318301 fax.+39.0658318303 P.I. 04856801008 **

*
*Rispetta l'ambiente e non stampare questa e-mail a meno che non ti sia
realmente utile.
Please consider the environment and don't print this e-mail unless you
really need to.

*NOTE SULLA PRIVACY*
Le informazioni trasmesse attraverso la presente e-mail ed i suoi
allegati sono diretti esclusivamente al
destinatario e devono ritenersi riservati con divieto di diffusione e di
uso. La diffusione e la comunicazione
da parte di soggetto diverso dal destinatario è vietata dall'art. 616 e
ss. c.p. e dal d. l.vo n. 196/03.
Se la presente e-mail ed i suoi allegati fossero stati ricevuti per
errore da persona diversa dal destinatario
siete pregati di distruggere tutto quanto ricevuto e di informare il
mittente con lo stesso mezzo.
________________________________________________________________________
Andrea P. (Guest)
on 2009-03-06 16:54
(Received via mailing list)
Ciao =)

non so se può essere di aiuto al tuo caso: da poco è nato questo progetto
che svolge qualcosa di molto vicino al risultato che vuoi ottenere. Si
tratta di una *database di hash* scritto in C ma ha i bindings per ruby,
python ed erlang. Stando alle intenzioni dell'autore, è stato creato per
avere dati persistenti e mantenere comunque prestazioni molto alte:

http://code.google.com/p/redis/

PS:
Approfitto per salutare la lista, mi chiamo Andrea P. e sono della
provincia di Roma. Da qualche tempo ho cominciato ad usare ruby (e RoR),
provengo già da altri linguaggi (dal C/C++/C# a PHP/Python, etc...), ma
Ruby
è quello che mi sta appassionando maggiormente =)

Sono utente (ed amministratore) Linux da quasi 10 anni, almeno su questo
potrei rendermi utile ^^

ciauz,
a.


Il giorno 4 marzo 2009 10.06, Mauro <removed_email_address@domain.invalid> ha 
scritto:
This topic is locked and can not be replied to.