[Python] python DB/TABLES ...

[Remo The Last]

...forse effettivamente c'è un pochino di nebbia nella mia logica e nel mio approccio.

Per fare l'esempio:
Lancio un traceroute e catturo gli indirizzi IP di ogni hop. 
L'indirizzo di ogni hop viene registrato in tabella in maniera successiva tipo hop1, hop2, hopn, ognuno con il proprio indirizzo IP.
Di per sè il traceroute è dinamico con hop che cambiano anche in numero e dunque devo creare dei hopn+1, hopn+2...  in più rispetto ad un traceroute precedente con numero inferiore di hop.

Come mi muovo con i campi delle tabelle? Da dove inizio? Come creo un campo per ogni hop successivo ovvero hopn++?  E ancora: gli hop devono essere indicizzati in ogni tabella per un approccio più facile.

 Cosa sbaglio o cosa non capisco?
py.Re




________________________________
 Da: Daniele Varrazzo <piro a develer.com>
A: python a lists.python.it 
Inviato: Sabato 11 Maggio 2013 16:26
Oggetto: Re: [Python] python DB/TABLES ...
 

On 2013-05-11 14:38, Remo The Last wrote:
> rispondo a tutti:
> chiedo scusa se non sono stato chiaro nel mio primo post.
> 
> Devo
>  iniziare a capire la creazione di DB in Python. Ne sono ignorante ma
> non sono un neofita della programmazione. E quello che mi serve è un
> buon inizio per imparare i DB relazionali in Python.

I db relazionali sono un mondo loro, e python è un mondo suo: non impari "i db in python". Fanno due cose diverse, per cui convivono bene. Se usi postgres (come detto da Manlio) hai il meglio che i db relazionali possano offrire oggi. Io mantengo psycopg, il driver python-postgres più usato, per cui se scegli questa strada penso tu sia in una botte di ferro, sia come solidità delle tecnologie scelte che come aiuto che puoi chiedere in giro (in lista ci sono altri utenti "pesanti" di postgres). Psycopg ha ottima documentazione per quanto riguarda l'integrazione python-postgres, postgres ha ottima documentazione di suo... ma sterminata.

Fidati di quello che ti hanno risposto gli altri: tabelle che "cambiano schema" a seconda dei dati contenuti sono solo il segnale di un problema non definito bene. Non dico che non sia consentito cambiare idea mentre si lavora, ma non è che i tuoi dati decideranno automaticamente lo schema: casomai te lo suggeriranno.


> Praticamente
>  devo creare una decina di tabelle con almeno una 30ina di campi
> all'interno di ogni tabella. Alcuni di questi campi sono uguali per
> tutte tabelle mentre altri campi saranno creati in funzione dei
> risultati delle elaborazioni. I contenuti dei campi creati saranno
> spesso tutti uguali, ma saranno identificati in maniera diversa per
> distinguere gli uni dagli altri. Dunque, nella la mia tabella dovrò
> creare in automatico dei campi per poter inserire (in funz. delle
> elaborazioni) dei dati che mi serviranno in seguito.

Un modo di risolvere il fatto di avere parte dei campi comuni si può fare con una tabella di base che contiene la parte comune, più una serie di tabelle in relazione 1-1 che contengono i campi estesi. Ma questo è un modo di memorizzare dati polimorfi (è simile a una classe python con delle sottoclassi che hanno attributi aggiuntivi) ma di cui conosci lo schema, non dove le tabelle vengono estese quando lo decidono i dati.

Se in partenza non conosci lo schema, in postgres hai almeno due modi di archiviare dati parzialmente strutturati, con la possibilità di strutturarli in seguito al sorgere delle necessità: il tipo hstore (http://www.postgresql.org/docs/9.2/static/hstore.html) è praticamente un dizionario str -> str e consente di fare alcune ricerche indicizzate (es. trovare i record che contengono la chiave 'x' oppure la chiave 'x' col valore 'y'). Un altro è usare JSON (http://www.postgresql.org/docs/9.2/static/datatype-json.html) e memorizzare dati completamente non strutturati, ma per indicizzare questi dati devi costruire degli indici ad hoc. psycopg offre conversioni hstore <-> dict (con dizionari che contengono solo chiavi str e valori str oppure None: http://initd.org/psycopg/docs/extras.html#hstore-data-type) e conversioni json <-> qualunque cosa supportata da funzioni load/dump: http://initd.org/psycopg/docs/extras.html#json-adaptation).


> E le tabelle
>  sono leggere; non saranno impegnative per la macchina.
> 
> Insomma mi serve un buon inizio, facile, intuitivo e veloce
> nell'apprendimento.

Te l'hanno detto già in 40: evita le tabelle dinamiche e tutto sarà facile. Prova la strada di tabelle che vengano estese automaticamente e... saranno cazzi tuoi :)


-- Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
_______________________________________________
Python mailing list
Python a lists.python.it
http://lists.python.it/mailman/listinfo/python
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130511/ee44d5a5/attachment-0001.html>