Memorizzare hash in un campo di una tabella


#1

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?


#2

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


#3

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.


#4

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


#5

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.


#6

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.


#7

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.



#8

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: