Re: [Python] info su db
Il giorno 05/mar/2014, alle ore 19:46, Daniele Varrazzo p...@develer.com ha scritto: Chiavi naturali/surrogate e chiavi singole/multiple sono battaglie già combattute e di cui si sa che non c'è vincitore. Che ne dici di una bella partita a scacchi? :) Mi arruolo nella pattuglia di 'id' per tutto. Non perchè sia 'meglio' ma solo perchè identifica un ben preciso record che ha un ben preciso contenuto. Certamente posso cercare in base al contenuto ma come pura comodità operativa uso sempre un'id con la sola eccezione di una chiave naturale certa e immutabile. Forse è pigrizia mentale ma in tutti questi anni ne sono sempre stato felice. Per inciso, non uso mai come id un numero ma un UUID. Anche qui sono certo che molti avranno da criticare in termini di prestazioni. Ma tutte le volte in cui ti trovi POI a far confluire dati che provengono da fonti diverse un UUID è una benedizione. G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 10:32 GMT+01:00 Giovanni Porcari giovanni.porc...@softwell.it: Ma tutte le volte in cui ti trovi POI a far confluire dati che provengono da fonti diverse un UUID è una benedizione. In effetti, se le performance non sono un fattore critico il discorso non fa una piega. Carlos -- Coloro che sognano di giorno sono uomini pericolosi, perche' sono capaci di recitare a occhi aperti il loro sogno fino a renderlo possibile. Ed e' questo che feci anch'io. - (T.E. Lawrence) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Ps. in telecom cerano anagrafiche intere con codice fiscale errato. chiaramente era chiave primaria. errare è umano ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 10:45 GMT+01:00 Simone Federici s.feder...@gmail.com: Ps. in telecom cerano anagrafiche intere con codice fiscale errato. chiaramente era chiave primaria. errare è umano Sed Telecom Diabolicum Est ;) Carlos -- Coloro che sognano di giorno sono uomini pericolosi, perche' sono capaci di recitare a occhi aperti il loro sogno fino a renderlo possibile. Ed e' questo che feci anch'io. - (T.E. Lawrence) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Carlos Catucci: Sed Telecom Diabolicum Est ;) eheheh, l'esempio è calzante. mai fidarsi di una chiave primaria semantica. meglio casuale, o per lo meno progressiva. figuratevi una chiave semantica multipla. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 10:32 GMT+01:00 Giovanni Porcari giovanni.porc...@softwell.it: Chiavi naturali/surrogate e chiavi singole/multiple sono battaglie già combattute e di cui si sa che non c'è vincitore. Che ne dici di una bella partita a scacchi? :) Mi arruolo nella pattuglia di 'id' per tutto. Non vorrei entrare nella discussione, si chiacchiera molto e non si converge su nulla, ma so gia' che avro' il tarlo per tutta la giornata. Forse è pigrizia mentale ma in tutti questi anni ne sono sempre stato felice. Se utilizzi o sviluppi un framework generico posso vedere la comodita'. Purtroppo molte persone scelgono lo stesso approccio per una ragione molto piu' mondana: non sono in grado, o non vogliono, scrivere una UI che possa gestire chiavi composte. E continueranno a pensare se posso fare un CRUD alla meno peggio, posso fare tutto Per inciso, non uso mai come id un numero ma un UUID. Anche qui sono certo che molti avranno da criticare in termini di prestazioni. Prestazioni, complessita' delle query e del codice dell'applicazione, duplicazione dei dati, e quant'altro. Soprattutto se il DB non permette constraint che possano mitigare il problema (es. maisql) Ma soprattutto quello che manca spesso in queste discussioni e' il contesto, ad esempio, una tabella che gestisce le iscrizioni ad un circolo di tennis, con una PK assegnata dal db, e' un perfetto esempio di chiave naturale. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Carlo Miron: spero non ci troveremo mai a lavorare assieme ;) non ci sperare troppo altrimenti poi si avvera. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On Thu, Mar 6, 2014 at 11:41 AM, Carlo Miron mi...@python.it wrote: Simone, Il 06 marzo 2014 10:53, Simone Federici s.feder...@gmail.com ha scritto:: mai fidarsi di una chiave primaria semantica. meglio casuale, o per lo meno progressiva. figuratevi una chiave semantica multipla. spero non ci troveremo mai a lavorare assieme ;) In questi casi mi spiace non essere un imprenditore di successo: vi assumerei entrambi e vi metterei sullo stesso progetto, chiusi in una stanza :-) Comunque io ho molto apprezzato, durante sessioni di debug, fare query in cui la chiave primaria era 'pippo-srl-12345678902' e non '234bdf3e'. Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-05 18:46 GMT+00:00 Daniele Varrazzo p...@develer.com: Questa guerra di religione è probabilmente più vecchia sia di Emacs che di Vi :) Ah, direi di no! I db relazionali sono relativamente recenti, almeno rispetto a vi. Ma il resto no: la tupla (id tag, id lettore, timestamp) non è pratica come chiave di una Lettura. Hai già bisogno di 6 campi per linkare due letture ad una Presenza, in più un timestamp è (praticamente) un valore reale, non discreto, e si presta male come identificativo (magari in postgres ha un numero di usec intero, poi passa attraverso python che lo converte in virgola mobile, fai una seconda query e ci scappa un arrotondamento di un milionesimo di secondo che te lo fa mancare). Il timestamp da solo, si. E' ovviamente non univoco (posso ampiamente avere due accessi allo stesso momento). Comunque se hai un db decente, puoi usare i tipi di dato appropriati. Sono favorevoli alle chiavi naturali, ma quando siano *veramente* univoche. Il che è più raro di quello che sembra. Una targa non identifica abbastanza bene un'auto (come feci in uno dei primi programmi che scrissi, e i venditori si sovrascrivevano a vicenda le auto da rendere nei preventivi, perché quando il cliente non ricordava a memoria la targa scrivevano tutti NON...). Non sono neanche univoche, come sanno quelli con targa CD ... .. che beccano le multe al posto di quelli del Corpo Diplomatico (che sono uguali ma scritte in blu...). Un codice fiscale non identifica abbastanza bene una persona: puoi non conoscerlo, può non averlo... E infatti io non parlavo di codice fiscale. Parlavo di employee ID, che per una serie di cose e' qualcosa che e' semanticamente significativo nel dominio applicativo. Non e' solo un artefatto del database... Il codice fiscale e' ovviamente una cattiva chiave (specie se non supponi di avere a che fare solo con italiani o residenti in italia). Allo stesso modo sono favorevole alle chiavi multiple, ma quando siano pratiche: in una tabella di unione molti-a-molti non ho problemi ad usare la coppia di pkey come pkey, ma non butto il sangue a cercarne una quando non è ovvia. Ma in questo caso una chiave e' ovvia. In un singolo istante, per un singolo lettore, puoi avere solo una lettura. Se pensi di non avere letture abbastanza granulari, puoi avere al limite anche la persona che ha badgato. Chiavi naturali/surrogate e chiavi singole/multiple sono battaglie già combattute e di cui si sa che non c'è vincitore. Che ne dici di una bella partita a scacchi? :) Non e' questione di vincere. E non ci siamo solo noi. Ci sono anche quelli che iniziano: per queste persone e' forse una buona cosa sapere che se e' vero che MySQL supporta(va) il modello relazionale in modo tragicomico, questo non vuole dire che bisogna pensare il db con uno schema errato per forza: si puo' usare una tecnologia che lavora bene. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 2014-03-06 09:59, Marco Mariani wrote: 2014-03-06 10:45 GMT+01:00 Simone Federici s.feder...@gmail.com: Ps. in telecom cerano anagrafiche intere con codice fiscale errato. chiaramente era chiave primaria. Ahahah, che cretini! http://developers.slashdot.org/story/14/02/11/0015242/surrogate-database-key-not-bitcoin-protocol-flaw-to-blame-for-mt-gox-problems Marco, sono tutti bravi col senno di poi. Uno punta a conoscere gli errori per evitarli, non per deridere chi li ha fatti. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 12:13 GMT+01:00 Marco Beri marcob...@gmail.com: In questi casi mi spiace non essere un imprenditore di successo: vi assumerei entrambi e vi metterei sullo stesso progetto, chiusi in una stanza :-) Ah non lo sei? Che ingiustizia! Adesso metto su un crowdfunding (in qualita' di presidente del tuo fan club mi sembra dovuto) per procurarti i fondi necessari a diventarlo, cosi' che puoi dare adito al tuo evil plan verso questi due ragazzuoli ;) -- Coloro che sognano di giorno sono uomini pericolosi, perche' sono capaci di recitare a occhi aperti il loro sogno fino a renderlo possibile. Ed e' questo che feci anch'io. - (T.E. Lawrence) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 12:13 GMT+01:00 Marco Beri marcob...@gmail.com: In questi casi mi spiace non essere un imprenditore di successo: vi assumerei entrambi e vi metterei sullo stesso progetto, chiusi in una stanza :-) come era quella, chi sa fa, chi non sa investe, chi non ha scrive libri. Comunque io ho molto apprezzato, durante sessioni di debug, fare query in cui la chiave primaria era 'pippo-srl-12345678902' e non '234bdf3e'. già non male, l'importante è che la chiave primaria non cambi mai. Speriamo che pippo srl non diventi mai pluto spa. Ma dai è chiaro che sarà un altra identità :-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 6 Mar 2014 12:33, Simone Federici s.feder...@gmail.com wrote: 2014-03-06 12:13 GMT+01:00 Marco Beri marcob...@gmail.com: In questi casi mi spiace non essere un imprenditore di successo: vi assumerei entrambi e vi metterei sullo stesso progetto, chiusi in una stanza :-) come era quella, chi sa fa, chi non sa investe, chi non ha scrive libri. Ahahahahah! :-) Comunque io ho molto apprezzato, durante sessioni di debug, fare query in cui la chiave primaria era 'pippo-srl-12345678902' e non '234bdf3e'. già non male, l'importante è che la chiave primaria non cambi mai. Speriamo che pippo srl non diventi mai pluto spa. Ma dai è chiaro che sarà un altra identità :-) Anche se fosse? Non vedo il problema di avere un id che sicuramente è univoco (ragione sociale più partita IVA per me lo sono, pur conoscendo i limiti di ognuna delle due parti) e che, nel 99.99% dei casi, ti dà anche un aiuto semantico in fase di debug o data mining. Ma attento: non sto dicendo che un approccio è (molto) meglio dell'altro. No Flame War :-) Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 12:43 GMT+01:00 Marco Beri marcob...@gmail.com: Ma attento: non sto dicendo che un approccio è (molto) meglio dell'altro. C'è uno che guarda giù da un ponte, un altro pelato arriva e gli chiede cosa stà guardando. Lui gli risponde che qualche giorno prima uno si è buttato giù e da allora è diventato famoso, aveva perso il lavoro e il soccorritore che lo ha salvato lo ha aiutato a ripartire. Morale: C'è sempre un modo di vedere le cose positive. PS. io non mi butto. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 12:50 GMT+01:00 Simone Federici s.feder...@gmail.com: 2014-03-06 12:43 GMT+01:00 Marco Beri marcob...@gmail.com: Ma attento: non sto dicendo che un approccio è (molto) meglio dell'altro. C'è uno che guarda giù da un ponte, un altro pelato arriva e gli chiede cosa stà guardando. Lui gli risponde che qualche giorno prima uno si è buttato giù e da allora è diventato famoso, aveva perso il lavoro e il soccorritore che lo ha salvato lo ha aiutato a ripartire. Morale: C'è sempre un modo di vedere le cose positive. PS. io non mi butto. Inutile: non ci casco :-) Ah, se vuoi sentire una spiegazione da uno più bravo di me, eccotela: http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-i-7327 http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-ii-7345 http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-iii-7365 A me questa lettura è molto servita (ci metterai 10 minuti a leggere tutto, non di più). Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 2014-03-06 11:17, enrico franchi wrote: 2014-03-05 18:46 GMT+00:00 Daniele Varrazzo p...@develer.com: Questa guerra di religione è probabilmente più vecchia sia di Emacs che di Vi :) Ah, direi di no! I db relazionali sono relativamente recenti, almeno rispetto a vi. vi è del 76, I db relazionali sono fatti originare da un articolo di Codd del 1970 (fonte: wikipedia). Ma il resto no: la tupla (id tag, id lettore, timestamp) non è pratica come chiave di una Lettura. Hai già bisogno di 6 campi per linkare due letture ad una Presenza, in più un timestamp è (praticamente) un valore reale, non discreto, e si presta male come identificativo (magari in postgres ha un numero di usec intero, poi passa attraverso python che lo converte in virgola mobile, fai una seconda query e ci scappa un arrotondamento di un milionesimo di secondo che te lo fa mancare). Il timestamp da solo, si. E' ovviamente non univoco (posso ampiamente avere due accessi allo stesso momento). Comunque se hai un db decente, puoi usare i tipi di dato appropriati. Postgres è un db decente: così tanto che potrebbe definire un timestamp con una precisione superiore a quella che può gestire un applicativo. Stai facendo un discorso da manuale (neanche tutti), io sto parlando in termini pratici. La tupla (lettore, tag, timestamp) è univoca, certo (nota: tag, non utente). È una buona chiave primaria? Tu hai letto dei libri che dicono di sì. Io ho letto dei libri che dicono di sì e dei libri che dicono di no. Ho scritto dei programmi ed ho la mia opinione, che è no, per la componente casuale della precisione con cui ogni sistema definisce i timestamp, perchè ogni url o form di ogni pagina web che devo generare sarà più complessa, e perchè ogni join è un dito al cubo (essendo tre i campi). E questo senza menzionare ORM non dico scritti coi piedi ma semplicemente non overingegnerizzati. Che magari non uso ora, ma in futuro chissà, e le basi di dati sono fatte per *sopravvivere* al codice: il tuo programma fra 5 anni magari non lo userà nessuno ma i dati che ha generato saranno un asset importante e altri programmi, che non sai con che tecnologia verranno scritti, li useranno. E infatti io non parlavo di codice fiscale. Parlavo di employee ID, che per una serie di cose e' qualcosa che e' semanticamente significativo nel dominio applicativo. Non e' solo un artefatto del database... L'employee id è un mito che esiste solo negli esempi con cui si scrivono gli articoli di database su come si fanno i join, non esiste nella realtà. Non ho lavorato in nessuna azienda che avesse un identificativo decente per tutti gli impiegati. Anche gli irregolari che fanno pulizia di tanto in tanto, anche l'amante dell'amministratore delegato che passa alla fine della riunione del consiglio di amministrazione, hanno un badge. La cosa più simile all'employee id è l'id sequenziale che il database gli ha assegnato quando è stato immesso nel sistema la prima volta. Il codice fiscale e' ovviamente una cattiva chiave (specie se non supponi di avere a che fare solo con italiani o residenti in italia). Com'è che è così evidente in una ML amatoriale ma non per gli ingegneri di Telecom? :) Allo stesso modo sono favorevole alle chiavi multiple, ma quando siano pratiche: in una tabella di unione molti-a-molti non ho problemi ad usare la coppia di pkey come pkey, ma non butto il sangue a cercarne una quando non è ovvia. Ma in questo caso una chiave e' ovvia. In un singolo istante, per un singolo lettore, puoi avere solo una lettura. Se pensi di non avere letture abbastanza granulari, puoi avere al limite anche la persona che ha badgato. Chiavi naturali/surrogate e chiavi singole/multiple sono battaglie già combattute e di cui si sa che non c'è vincitore. Che ne dici di una bella partita a scacchi? :) Non e' questione di vincere. (peccato, citazione mancata :) E non ci siamo solo noi. Ci sono anche quelli che iniziano: per queste persone e' forse una buona cosa sapere che se e' vero che MySQL supporta(va) il modello relazionale in modo tragicomico, questo non vuole dire che bisogna pensare il db con uno schema errato per forza: si puo' usare una tecnologia che lavora bene. Vabbè passiamo a bashare la cosa che tutti amano bashare (ancora, spesso comicamente senza sapere quello che dicono e pensando di essere depositari di chissà che conoscenza). Ora ci sarà anche il coretto di tutti gli iscritti che la sanno lunga e +1 e haha che cretini... MySql non l'ha nominato nessuno, non stiamo parlando di database buoni o cattivi qui. Io uso Postgres e una chiave primaria tripla con dentro un valore reale la considero un'idea abbastanza cattiva da meritare una chiave surrogata, sebbene il database sia perfettamente in grado di gestirla. Tu no? Ok, ma sono opinioni, non oro colato: quello che pensi non è giusto in assoluto. Per te ha dei vantaggi. Che peraltro non hai ancora elencato: hai solo
Re: [Python] info su db
On 2014-03-06 12:28, Luciano Trespidi wrote: scusate posso intervenire ? Certo, ma ti prego, scrivi la tua risposta sotto, non sopra. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 13:28 GMT+01:00 Luciano Trespidi keple...@hotmail.com: scusate posso intervenire ? Non c'è nemmeno da chiedere! Ma visto che lo chiedi: sì, a patto che quoti come si deve :-) Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Inviato da : Ernesto Luciano Trespidi email: keple...@hotmail.com Tel: 3299255463 Il giorno 06/mar/2014, alle ore 13:29, Daniele Varrazzo p...@develer.com ha scritto: On 2014-03-06 12:28, Luciano Trespidi wrote: scusate posso intervenire ? Certo, ma ti prego, scrivi la tua risposta sotto, non sopra. -- Daniele sono un neofita e volevo sapere se esiste un programma serio Free per editare e compilare python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Il 06/mar/2014 13:34 Luciano Trespidi keple...@hotmail.com ha scritto: sono un neofita e volevo sapere se esiste un programma serio Free per editare e compilare python Bene... Benvenuto, come neofita hai già cominciato con il piede sbagliato ;) Sul quote tu hanno già detto qualcosa, e vedo che ne hai già fatto tesoro (va a tuo merito, ci sono partecipanti che anche dopo parecchie ripetizioni non hanno ancora capito), la seconda lezione è: Cancella tutto quello che non serve alla tua risposta (comprese le firme in coda e i disclaimer inseriti dai server di gestione della posta e delle ml). Terza ed ultima lezione, per il momento, è quella di non cominciare mai un nuovo argomento come risposta ad una mail qualsiasi della ml Quindi ti consiglio di riformulare la tua domanda in in nuovo post, e vedrai che otterrai sicuramente risposte soddisfacenti. byez -- Gollum1 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 13:23 GMT+01:00 Daniele Varrazzo p...@develer.com: E questo senza menzionare ORM non dico scritti coi piedi ma semplicemente non overingegnerizzati. Che magari non uso ora, ma in futuro chissà, e le basi di dati sono fatte per *sopravvivere* al codice: il tuo programma fra 5 anni magari non lo userà nessuno ma i dati che ha generato saranno un asset importante e altri programmi, che non sai con che tecnologia verranno scritti, li useranno. Vero! Forse e' capitato anche a voi... trovarsi 1000+ tabelle senza alcuna foreign key, senza alcuna chiave naturale, senza constraint, con una media di 80-85 colonne per tabella. Il tutto da migrare a una struttura NoSQL Senza foreign key significa che neppure le colonne ID erano relazionate tra loro. Ho dovuto scrivere un programma per cercare le relazioni sulla base dei contenuti. E molti test manuali. Avrei dato il braccio destro perche', come minima regola igienica di base, ci fosse stato uno straccio di chiave naturale univoca. Ma sono sicuro che l'ORM e il CRUD funzionavano alla perfezione in quel programma. Perche' nei dati c'erano un sacco di schifezze, ma dall'interfaccia non si vedevano. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 13:23 GMT+01:00 Daniele Varrazzo p...@develer.com: L'employee id è un mito che esiste solo negli esempi con cui si scrivono gli articoli di database su come si fanno i join, non esiste nella realtà. Non ho lavorato in nessuna azienda che avesse un identificativo decente per tutti gli impiegati. +1. C'è la matricola, ma è valida solo per gli impiegati, per o co-co-co o derivati, no. Per i partita iva no. La matricola riparte da zero se l'azienda cambia nome, ogni impiegato ha quindi un vecchia matricola e una nuova, per lo meno all'inizio. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Inviato da : Ernesto Luciano Trespidi email: keple...@hotmail.com Tel: 3299255463 Il giorno 06/mar/2014, alle ore 14:41, Gollum1 gollum1.smeag...@gmail.com ha scritto: Il 06/mar/2014 13:34 Luciano Trespidi keple...@hotmail.com ha scritto: sono un neofita e volevo sapere se esiste un programma serio Free per editare e compilare python Bene... Benvenuto, come neofita hai già cominciato con il piede sbagliato ;) Sul quote tu hanno già detto qualcosa, e vedo che ne hai già fatto tesoro (va a tuo merito, ci sono partecipanti che anche dopo parecchie ripetizioni non hanno ancora capito), la seconda lezione è: Cancella tutto quello che non serve alla tua risposta (comprese le firme in coda e i disclaimer inseriti dai server di gestione della posta e delle ml). Terza ed ultima lezione, per il momento, è quella di non cominciare mai un nuovo argomento come risposta ad una mail qualsiasi della ml Quindi ti consiglio di riformulare la tua domanda in in nuovo post, e vedrai che otterrai sicuramente risposte soddisfacenti. Hai ragione mi devi scusare ma sono agli inizi ! Errare umanum est . byez -- Gollum1 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 17:16 GMT+01:00 Luciano Trespidi keple...@hotmail.com: Errare umanum est . Pherseverare Diabolichum... :-D Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 14:56 GMT+01:00 Marco Mariani bir...@gmail.com: Avrei dato il braccio destro perche', come minima regola igienica di base, ci fosse stato uno straccio di chiave naturale univoca. Non hai specificato di chi. Lo so in fondo c'e' tanta gente, quindi va bene uno qualsiasi. Esatto disse Ligur. Il braccio destro di chiunque, pensò. C'erano così tante braccia in giro che sarebbe stato uno spreco rinunciare a uno buono. (Neil Gaiman terry Pratchet - Good Omens) Carlos -- Coloro che sognano di giorno sono uomini pericolosi, perche' sono capaci di recitare a occhi aperti il loro sogno fino a renderlo possibile. Ed e' questo che feci anch'io. - (T.E. Lawrence) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 06/03/2014 13:35, Luciano Trespidi wrote: On 2014-03-06 12:28, Luciano Trespidi wrote: scusate posso intervenire ? sono un neofita e volevo sapere se esiste un programma serio Free per editare e compilare python Scusa Luciano, ma ROTFL! Che spettacolo Benvenuto nella lista! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 06/03/2014 13:23, Daniele Varrazzo wrote: Che ne dici di una bella partita a scacchi Wargames.. questa era difficile! Cult fichissimo!! ..nel contesto comunque preferisco la guerra termonucleare globale perche' lurko da paura :) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 18:14 GMT+01:00 Diego Barrera diegonebarr...@yahoo.it: On 06/03/2014 13:23, Daniele Varrazzo wrote: Che ne dici di una bella partita a scacchi Wargames.. questa era difficile! Cult fichissimo!! ..nel contesto comunque preferisco la guerra termonucleare globale perche' lurko da paura :) https://www.youtube.com/watch?v=v11Y64dnnF4#t=34s Vedo che non sono l'unico vecchio in lista :-) Tuo anno di nascita? Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 18:30 GMT+01:00 Marco Beri marcob...@gmail.com: Vedo che non sono l'unico vecchio in lista :-) Se conoscere una partita a scacchi così storica significa essere vecchi allora sono vecchio anche io. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 18:32 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com: 2014-03-06 18:30 GMT+01:00 Marco Beri marcob...@gmail.com: Vedo che non sono l'unico vecchio in lista :-) Tuo anno di nascita? Cosa c'entra l'eta' (cerebrale) con l'anno di nascita? Io sono del 60 ma ho 14 anni (mia moglie puo' confermare, lo dice sempre che ragiono come un 14enne) ;) :-) Beh, d'accordo, anche io sono sul 23enne andante. Ma un 14enne di oggi difficilmente ha visto (e se avesse visto, avrebbe apprezzato nei dettagli) Wargames. Non trovi? Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 18:38 GMT+01:00 Marco Beri marcob...@gmail.com: Ma un 14enne di oggi difficilmente ha visto (e se avesse visto, avrebbe apprezzato nei dettagli) Wargames. Non trovi? E chi ha detto che io lo abbia apprezzato nei dettagli? Tra i miei cult, sorry, lui non c'e'. Ma andiamo davvero OT mi sa. Carlos -- Coloro che sognano di giorno sono uomini pericolosi, perche' sono capaci di recitare a occhi aperti il loro sogno fino a renderlo possibile. Ed e' questo che feci anch'io. - (T.E. Lawrence) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 18:43 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com: 2014-03-06 18:38 GMT+01:00 Marco Beri marcob...@gmail.com: Ma un 14enne di oggi difficilmente ha visto (e se avesse visto, avrebbe apprezzato nei dettagli) Wargames. Non trovi? E chi ha detto che io lo abbia apprezzato nei dettagli? Tra i miei cult, sorry, lui non c'e'. Ma andiamo davvero OT mi sa. Come diceva Oscar Wilde: Toglietemi tutto tranne gli OT. :-) -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 18:47 GMT+01:00 Marco Beri marcob...@gmail.com: Come diceva Oscar Wilde: Toglietemi tutto tranne gli OT. Io mi ricordo Cindy Crawford e parlava dell'orologio (apprezzavo il toglierle tutto pero', all'epoca, lasciarle l'orologio non mi dava alcun problema) Carlos -- Coloro che sognano di giorno sono uomini pericolosi, perche' sono capaci di recitare a occhi aperti il loro sogno fino a renderlo possibile. Ed e' questo che feci anch'io. - (T.E. Lawrence) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 06/03/2014 18:30, Marco Beri wrote: https://www.youtube.com/watch?v=v11Y64dnnF4#t=34s Vedo che non sono l'unico vecchio in lista :-) Tuo anno di nascita? Mi dispiace.. 1980! ;) http://docmanhattan.blogspot.it/2013/04/20-cose-che-forse-non-sapevate-su-wargames-giochi-di-guerra.html Leggere fino in fondo! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 21:18 GMT+01:00 Diego Barrera diegonebarr...@yahoo.it: On 06/03/2014 18:30, Marco Beri wrote: https://www.youtube.com/watch?v=v11Y64dnnF4#t=34s Vedo che non sono l'unico vecchio in lista :-) Tuo anno di nascita? Mi dispiace.. 1980! ;) Orpo... tre anni sono davvero pochi per averlo visto :-) http://docmanhattan.blogspot.it/2013/04/20-cose-che-forse-non-sapevate-su-wargames-giochi-di-guerra.html Leggere fino in fondo! Aha! Non lo conoscevo, molto interessante e ben fatto! Leggere il punto 8 mi ha fatto piacere. Quando l'avevo visto al cinema, avevo pensato che il computer non poteva metterci lo stesso tempo a trovare la prima cifra rispetto all'ultima: avrebbe dovuto trovarne una nuova sempre più velocemente. Certo, era un assurdo comunque visto che avrebbe dovuto scoprirle tutte in una volta o niente, ma ai tempi non avevo nemmeno un computer, nonostante fossi già ventenne, che potevo pretendere? :-) Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Il 06 marzo 2014 18:35, Simone Federici s.feder...@gmail.com ha scritto: Se conoscere una partita a scacchi così storica significa essere vecchi allora sono vecchio anche io. Scusate, ma perché parlate di scacchi? Non era una partita a filetto (tris, tic tac toe)? Ciao -- Daniele www.fugamatematica.blogspot.com giusto! nel verso forse è perché non guardiamo le cose Quando non ci capiamo, ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-06 21:53 GMT+01:00 Daniele Zambelli daniele.zambe...@gmail.com: Il 06 marzo 2014 18:35, Simone Federici s.feder...@gmail.com ha scritto: Se conoscere una partita a scacchi così storica significa essere vecchi allora sono vecchio anche io. Scusate, ma perché parlate di scacchi? Non era una partita a filetto (tris, tic tac toe)? La partita a filetto fu usata per fermare il super computer, il quale, al momento del raggiungimento della consapevolezza di non poter vincere nemmeno al gioco guerra termonucleare globale chiese al professore Che ne pensa di una bella partita a scacchi :-) Quindi hai ragione, non c'era nessuna partita a scacchi, ciò nondimeno la frase rimase epica per il senso di liberazione che la accompagnava. Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 2014-03-06 20:18, Diego Barrera wrote: http://docmanhattan.blogspot.it/2013/04/20-cose-che-forse-non-sapevate-su-wargames-giochi-di-guerra.html Bell'articolo, grazie :) -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Direi che la cosa migliore è creare una tabella di anagrafica degli utenti collegata con una relazione uno-molti a una tabella per gestire gli ingressi e a una per le uscite. ciao, Cristian Il giorno mer, 05/03/2014 alle 12.16 +0100, Perini Matteo ha scritto: Ciao a tutti, dopo un po' di stallo riprendo la questione db con nuove domande. Prescindendo dal tipo di db scelto Dovrei usare il db per immagazzinare tutte le info degli utenti, e fin qui non ci sono problemi. Ad ogni utente è assegnato un codice (ID) contenuto in una tessera con chip RFID. Ad ogni ingresso/uscita gli utenti devono passare la tessera su un lettore e in quel momento la data e l'ora devono essere immagazzinate da qualche parte nel db. Forse è una domanda stupida ma come è meglio creare la struttura della tabella per ottenere lo scopo? Ad es: ID | Nome | Cognome | Data e Ora | segni particolari | Ecc.. e ogni volta che viene strisciata la tessera vado a fare un append al campo Data e Ora dell'utente? Può essere corretto? Meglio separare ingresso e uscita? tipo cosi: ID | Nome | Cognome | Data e Ora Ingresso | Data e Ora uscita | E' dentro? | segni particolari | Ecc.. Ci sono altri modi? Ad esempio per sapere il tempo di permanenza di un utente dovrei fare le differenze tra tempi di ingresso e uscita ma devo prevedere che una persona dimentichi di strisciare in ingresso o in uscita... e le cose si complicano. Avete consigli? Grazie Matteo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 2014-03-05 11:16, Perini Matteo wrote: Ciao a tutti, dopo un po' di stallo riprendo la questione db con nuove domande. Prescindendo dal tipo di db scelto Dovrei usare il db per immagazzinare tutte le info degli utenti, e fin qui non ci sono problemi. Ad ogni utente è assegnato un codice (ID) contenuto in una tessera con chip RFID. Ad ogni ingresso/uscita gli utenti devono passare la tessera su un lettore e in quel momento la data e l'ora devono essere immagazzinate da qualche parte nel db. Forse è una domanda stupida ma come è meglio creare la struttura della tabella per ottenere lo scopo? Ad es: ID | Nome | Cognome | Data e Ora | segni particolari | Ecc.. e ogni volta che viene strisciata la tessera vado a fare un append al campo Data e Ora dell'utente? Può essere corretto? Meglio separare ingresso e uscita? tipo cosi: ID | Nome | Cognome | Data e Ora Ingresso | Data e Ora uscita | E' dentro? | segni particolari | Ecc.. Dovresti studiare qualcosa di molto elementare sui database: non puoi replicare informazioni su nome e cognome ad ogni strisciata, altrimenti è un log non relazionale, tanto vale tu lo scriva in un file. Le informazioni sugli utenti e le strisciate devono essere in due tabelle diverse. Separare nome è cognome è un'idea regolare, ma un po' limitata (ho sempre l'esempio del mio collega che non ha il cognome). Avere sia data ingresso che data uscita nello stesso record è giustissima: se un record rappresenta un periodo devono essere riportati sia inizio che fine, usare il record di prima come inizio porta a complicazioni terribili. L'informazione è dentro può essere dedotta dal fatto che una presenza abbia la data uscita nulla. Peraltro un utente non è collegato ad una lettura: un tag lo è, quindi secondo me dovresti avere come minimo: Utente: id, nome, cognome, indirizzo ecc.. Tag: id (del db, forse non necessario), identificativo (quello che il lettore legge), emesso il, ritirato il, motivo del ritiro ecc. Utente per tag: quale utente, quale tag, da quando l'ha avuto, fino a quando l'ha avuto. Lettura: id, quale tag, quale lettore, a che ora. Presenza: id lettura in, id lettura out. Lettore: id, ...tutte le informazioni che servono Nota che una lettura è un evento imprescindibile: quella cosa è successa. Una presenza è una policy: mette in relazione due letture nel caso più normale ma potrebbero succedere cose strane: tipo uno che entra ed esce in modo imprevisto (in barella? o semplicemente il lettore era rotto?) per cui mi sembra giusto separare le Letture (da registrare) dalle Presenze (da ricostruire). Potresti anche avere quello che entra, passa il tag a quello dietro e quello entra anche lui: è vietato da una policy, non dalla fisica. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
Il 05/03/2014 17:21, Daniele Varrazzo ha scritto: Dovresti studiare qualcosa di molto elementare sui database: non puoi replicare informazioni su nome e cognome ad ogni strisciata, altrimenti è un log non relazionale, tanto vale tu lo scriva in un file. Le informazioni sugli utenti e le strisciate devono essere in due tabelle diverse. Separare nome è cognome è un'idea regolare, ma un po' limitata (ho sempre l'esempio del mio collega che non ha il cognome). Avere sia data ingresso che data uscita nello stesso record è giustissima: se un record rappresenta un periodo devono essere riportati sia inizio che fine, usare il record di prima come inizio porta a complicazioni terribili. L'informazione è dentro può essere dedotta dal fatto che una presenza abbia la data uscita nulla. Peraltro un utente non è collegato ad una lettura: un tag lo è, quindi secondo me dovresti avere come minimo: Utente: id, nome, cognome, indirizzo ecc.. Tag: id (del db, forse non necessario), identificativo (quello che il lettore legge), emesso il, ritirato il, motivo del ritiro ecc. Utente per tag: quale utente, quale tag, da quando l'ha avuto, fino a quando l'ha avuto. Lettura: id, quale tag, quale lettore, a che ora. Presenza: id lettura in, id lettura out. Lettore: id, ...tutte le informazioni che servono Nota che una lettura è un evento imprescindibile: quella cosa è successa. Una presenza è una policy: mette in relazione due letture nel caso più normale ma potrebbero succedere cose strane: tipo uno che entra ed esce in modo imprevisto (in barella? o semplicemente il lettore era rotto?) per cui mi sembra giusto separare le Letture (da registrare) dalle Presenze (da ricostruire). Potresti anche avere quello che entra, passa il tag a quello dietro e quello entra anche lui: è vietato da una policy, non dalla fisica Grazie a tutti delle risposte, non ho risposto subito perché ho passato il pomeriggio a studiare ;) Ho capito che devo fare svariate tabelle collegate tra loro e che contengano tutti i dati. Intanto farò qualche prova poi ritornerò con le domande. Ciao Matteo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-05 16:21 GMT+00:00 Daniele Varrazzo p...@develer.com: Separare nome è cognome è un'idea regolare, ma un po' limitata (ho sempre l'esempio del mio collega che non ha il cognome). Interessante... non ci avevo effettivamente pensato. Piu' ci sono tutte le magagne su middle name (che da noi e' poco comune) et similia. Avere sia data ingresso che data uscita nello stesso record è giustissima: se un record rappresenta un periodo devono essere riportati sia inizio che fine, usare il record di prima come inizio porta a complicazioni terribili. +1 Utente: id, nome, cognome, indirizzo ecc.. Tag: id (del db, forse non necessario), identificativo (quello che il lettore legge), emesso il, ritirato il, motivo del ritiro ecc. Utente per tag: quale utente, quale tag, da quando l'ha avuto, fino a quando l'ha avuto. Lettura: id, quale tag, quale lettore, a che ora. Presenza: id lettura in, id lettura out. Lettore: id, ...tutte le informazioni che servono Io andrei piano con tutti questi id. Quando c'e' un ID naturale, niente da dire (e.g., employee id). Pero' mettere gli ID per non usare chiavi primarie vere, non mi piace tanto. Tipicamente un evento di lettura e' verosimilmente identificato univocamente da utente, ora, verosimilmente quale lettore lo ha fatto. Nota che una lettura è un evento imprescindibile: quella cosa è successa. Una presenza è una policy: mette in relazione due letture nel caso più normale ma potrebbero succedere cose strane: tipo uno che entra ed esce in modo imprevisto (in barella? o semplicemente il lettore era rotto?) per cui mi sembra giusto separare le Letture (da registrare) dalle Presenze (da ricostruire). Potresti anche avere quello che entra, passa il tag a quello dietro e quello entra anche lui: è vietato da una policy, non dalla fisica. +1 Inoltre, a meno che non abbiano policy molto strette, si scazzeranno sempre le cose. Tipo in un dc tenuto bene ti vengono a prendere se sei nella stanza sbagliata perche' hai tailato o hai chiuso una porta senza passarla. Ma se questo non avviene, ti trovi con un maciello. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 2014-03-05 17:05, enrico franchi wrote: 2014-03-05 16:21 GMT+00:00 Daniele Varrazzo p...@develer.com: Utente: id, nome, cognome, indirizzo ecc.. Tag: id (del db, forse non necessario), identificativo (quello che il lettore legge), emesso il, ritirato il, motivo del ritiro ecc. Utente per tag: quale utente, quale tag, da quando l'ha avuto, fino a quando l'ha avuto. Lettura: id, quale tag, quale lettore, a che ora. Presenza: id lettura in, id lettura out. Lettore: id, ...tutte le informazioni che servono Io andrei piano con tutti questi id. Quando c'e' un ID naturale, niente da dire (e.g., employee id). Pero' mettere gli ID per non usare chiavi primarie vere, non mi piace tanto. Tipicamente un evento di lettura e' verosimilmente identificato univocamente da utente, ora, verosimilmente quale lettore lo ha fatto. Questa guerra di religione è probabilmente più vecchia sia di Emacs che di Vi :) La penso come te: se vedi nei miei esempi ho dato un forse a mettere l'id su un tag. Non conosco la tecnologia, ma probabilmente l'identificativo pubblico è sufficiente. Ma il resto no: la tupla (id tag, id lettore, timestamp) non è pratica come chiave di una Lettura. Hai già bisogno di 6 campi per linkare due letture ad una Presenza, in più un timestamp è (praticamente) un valore reale, non discreto, e si presta male come identificativo (magari in postgres ha un numero di usec intero, poi passa attraverso python che lo converte in virgola mobile, fai una seconda query e ci scappa un arrotondamento di un milionesimo di secondo che te lo fa mancare). Sono favorevoli alle chiavi naturali, ma quando siano *veramente* univoche. Il che è più raro di quello che sembra. Una targa non identifica abbastanza bene un'auto (come feci in uno dei primi programmi che scrissi, e i venditori si sovrascrivevano a vicenda le auto da rendere nei preventivi, perché quando il cliente non ricordava a memoria la targa scrivevano tutti NON...). Non sono neanche univoche, come sanno quelli con targa CD ... .. che beccano le multe al posto di quelli del Corpo Diplomatico (che sono uguali ma scritte in blu...). Un codice fiscale non identifica abbastanza bene una persona: puoi non conoscerlo, può non averlo... Allo stesso modo sono favorevole alle chiavi multiple, ma quando siano pratiche: in una tabella di unione molti-a-molti non ho problemi ad usare la coppia di pkey come pkey, ma non butto il sangue a cercarne una quando non è ovvia. Chiavi naturali/surrogate e chiavi singole/multiple sono battaglie già combattute e di cui si sa che non c'è vincitore. Che ne dici di una bella partita a scacchi? :) -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
On 5 Mar 2014 19:46, Daniele Varrazzo p...@develer.com wrote: Chiavi naturali/surrogate e chiavi singole/multiple sono battaglie già combattute e di cui si sa che non c'è vincitore. +1 Che ne dici di una bella partita a scacchi? :) Da finire rigorosamente in stallo :-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] info su db
2014-03-05 12:31 GMT+01:00 Cristian Di Stefano cristian.distef...@isprambiente.it: Direi che la cosa migliore è creare una tabella di anagrafica degli utenti collegata con una relazione uno-molti a una tabella per gestire gli ingressi e a una per le uscite. +1 Carlos -- Coloro che sognano di giorno sono uomini pericolosi, perche' sono capaci di recitare a occhi aperti il loro sogno fino a renderlo possibile. Ed e' questo che feci anch'io. - (T.E. Lawrence) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
