Re: [Python] python SQL?
Ciao Carlos, On Sunday 16 February 2014 08:51:36 Carlos Catucci wrote: il poter svilupppare in locale, per dire, su Sqlite e poi andare in produzione con Postgres, cosa che mi facilita di molto le cose ... e ti fa attendere il deploy sullo staging server per scoprire eventuali problemi legati all'uso di un database diverso da quello di produzione! :-) -- Daniele Tricoli 'Eriol' http://mornie.org ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 10:15 GMT+01:00 Daniele Tricoli er...@mornie.org: ... e ti fa attendere il deploy sullo staging server per scoprire eventuali problemi legati all'uso di un database diverso da quello di produzione! :-) Beh che vuoi, nessuno e' perfetto ;) Comunque posso fare una macchina di test uguale a quella di produzione da subito e fare le prove, pero' per il quotidiano se il progetto e' condiviso, aiuta. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On Sunday 16 February 2014 10:35:51 Carlos Catucci wrote: Beh che vuoi, nessuno e' perfetto ;) Mai detto il contrario! :-) Comunque posso fare una macchina di test uguale a quella di produzione da subito e fare le prove, pero' per il quotidiano se il progetto e' condiviso, aiuta. Sì certo, il mio pensiero, appunto è che bisogna comunque conoscere il tradeoff che si fa utilizzando una determinata soluzione, soprattutto visto che l'OP si sta affacciando per la prima volta su questo specifico argomento. L'ORM ti dà flessibilità, ma ti nasconde feature specifiche di un determinato database, e la domanda da porsi, IMHO, è: quanto costa tale flessibilità? E quanto senso ha accettare tale costo? Per la maggior parte dei progetti il costo sarà anche nullo (anche in termini di debito tecnologico), ma non possiamo escludere che in alcuni casi la flessibilità di poter cambiare database di produzione è una feature che non verrà mai sfruttata. :-) Per quanto riguarda il testing, nel caso in cui lavorassimo ad un progetto insieme ti proporrei, al posto di un database SQLite da condividere, di usare un ORM (così si fa in fretta :D) per creare delle testsuite al volo (da poi integrare correttamente però) per poter dire cose del tipo: «Carlos, dai un'occhiata a sandobox/eriol/test_for_1234.py?» Dove test_for_1234.py andrebbe a mettere in evidenza il problema creando da zero il database e riempiendolo[¹]. Uno dei vantaggi che mi viene subito in mente è che nel caso in cui stessimo indagando problemi diversi che impattano la stessa parte del database, possiamo condividere il problema senza dover condividere due db SQLite, ad esempio. Ma la parte più importante è l'essersi messi d'accordo tra noi su come fare il testing condiviso! :-) Buona domenica, [¹] niente fixture please ;-) -- Daniele Tricoli 'Eriol' http://mornie.org ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 7:51 GMT+00:00 Carlos Catucci carlos.catu...@gmail.com: De gustibus non disputandum est. Sulle cose tecniche di solito non e' questione di *gusti*. Ci sono due questioni principali. Una completamente filosofica: 1. Ci sono un botto di pattern architetturali per fare ORM. I piu' popolari fuori da casa ms sono active record e data mapper. Guarda caso, nessuno dei due e' perfetto. Il motivo e' che il problema di mappare il modello relazionale sul modello ad oggetti e' vagamente ill-defined per vari motivi (fra cui il fatto che il modello ad oggetti e' un pochetto ill-defined di suo e soprattutto tende ad ammettere piu' soluzioni ad uno stesso problema con differenti trade-offs). Per cui anche a livello teorico si hanno vari compromessi... e.g., il design di active record e' molto leaky, data mapper e' relativamente complesso concettualmente. Ma poi proprio semplicemente ci sono cose molto naturali nel mondo ad oggetti che si mappano malissimo nel mondo relazionale e viceversa. E per queste situazioni l'orm non e' che puo' fare davvero molto... La seconda molto pratica: quello che e' un ORM e' un oggetto appiccicato sopra uno dei colli di bottiglia tipici delle applicazioni. Il che vuole dire che e' veramente molto sensibile alle performance. E semplifica molto la scrittura di query inefficienti. Ora, come si puo' notare dalla permanenza in una qualunque lista come questa, se le persone hanno una feature vagamente comoda da usare, ne abuseranno inconsapevolmente, insegneranno ad altri il loro trucco e poi si lamenteranno che tutto va piano (appena i dati crescono). Siccome sono clueless, ovviamente non avranno idea di quello che e' successo e risolveranno in vari modi (prendendo un consulente, generalmente per un altro linguaggio, cambieranno database, riscriveranno tutto, andranno avanti a lamentarsi senza fare nulla, dando la colpa a componenti casuali dell'architettura). Ora in tutto questo non e' che ci sia nulla di male, semplicemente il fatto e' che cose facili da fare e drammaticamente inefficienti saranno fatte *inconsapevolmente*. Il punto chiave e' che la gente pensa architetture varie ad oggetti e sfruttera' la flessibilita' dell'orm per martellarci dentro il pattern di accesso ai dati che piu' gli pare, non necessariamente uno buono. Su tutto questo, si infila il problemino tipico dei linguaggi ad oggetti: i dati occupano quintali di memoria non necessaria perche' sono pesantemente nested. E avere un sistema comodo per generare una comoda interfaccia ad oggetti vuole dire che le cose saranno fatte cosi'. E voglio dire... ricordati che i dati nel db sono, auspicabilmente univoci. tipicamente hai un db per applicazione, dentro cui hai i dati. un db logico: potrebbe essere shardato, auspicabilmente e' replicato, etc etc etc. I dati sono li e non danno fastidio. Poi scopri che hai una piccola flotta di server. Ciascuno di questi tira su un po' di worker. Ed ecco che le query che ti tirano su x MB di oggetti, in realta' finisce che ti tirano su x00 MB *globalmente*. E cominci ad avere problemi. E si, memcache, orpelli, cazzi e mazzi. Oh, poi voglio dire, se hai un magazzino con duemila oggetti, chissene. Se devi fare il payroll per duecento dipendenti, chissene. Se devi fare il blog, il forum e chissene... il problema e' che non scala. Non scala. Non ci sono cazzi. Io personalmente li trovo comodi. Il non dover impazzire tra dialetti, il poter svilupppare in locale, per dire, su Sqlite e poi andare in produzione con Postgres, cosa che mi facilita di molto le cose (per dirne una se aggiungo dati di test alla base dati un push sul repo condiviso (*) rende disponibile la cosa a tutti i coinvolti nel progetto senza dover eseguire un dump da allegare e un db_restore dopo un pull) senza impazzire sui dialetti e sulle varie differenze (sacrosante, ciascun Db ha il suo motivo di esistere, di essere specializzato in qualcosa, tranne forse un paio). Comodo, forse. Stiamo pero' contando *molto* che l'astrazione sia perfetta e non si stia nascondendo un baco che ti comparira' sulle macchine di test o addirittura in produzione. Vuole anche dire che non puoi usare nulla di specifico di PostgreSQL, che, sebbene accettabile, e' comunque una forte limitazione. Poi ovvio che se devo fare una query particolarmente incasinata (e accade SOLO se lavoro su basi dati esistenti, in caso contrario se e' roba mia parto dal presupposto di avere sbagliato l'architettura e riprogetto di conseguenza) posso usrae una raw, ma deve essere davvero un caso limite dove l'ORM non ce la fa. L'architettura del db deve essere *sempre* il piu' efficiente possibile. Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'. Il problema e' che anche su query relativamente semplici succedono cose. Lo so, mi direte che l'ORM non ottimizza come puo' fare una query scritta ad hoc, ma a volte la flessibilita' conta piu' delle prestazioni. Non nel mio caso. Aggiungere host non necessari cessa di
Re: [Python] python SQL?
On 16/02/2014 12:40, enrico franchi wrote: L'architettura del db deve essere *sempre* il piu' efficiente possibile. Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'. Alla luce di questo e avendo in mente che devo andare in produzione il prima possibile, (leggi per ora mi interessa poco scalare, ma mi server avere una killer app per vedere come va) che succede se opero in questo modo: 1. creo model e tutta app con l'orm; 2. l'app funziona e ho tanti clienti: primi problemi a scalare 3. ottimizzo sql e impostazioni specifiche dbms Mi sembra un buon compromesso. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
per cose piccole, SQLite Il giorno 16 febbraio 2014 13:33, Diego Barrera diegonebarr...@yahoo.itha scritto: On 16/02/2014 12:40, enrico franchi wrote: L'architettura del db deve essere *sempre* il piu' efficiente possibile. Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'. Alla luce di questo e avendo in mente che devo andare in produzione il prima possibile, (leggi per ora mi interessa poco scalare, ma mi server avere una killer app per vedere come va) che succede se opero in questo modo: 1. creo model e tutta app con l'orm; 2. l'app funziona e ho tanti clienti: primi problemi a scalare 3. ottimizzo sql e impostazioni specifiche dbms Mi sembra un buon compromesso. ___ 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] python SQL?
On 15/02/2014 20:55, Carlos Catucci wrote: 2014-02-15 19:56 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com mailto:manlio.peri...@gmail.com: ma senza l'ORM, solo sqlalchemy.sql Per curiosita' da ignorante, ma perche' non l'ORM? Non ti piaciono gli orm o e' un qualcosa di SQLAllchemy in particolare che non va? Perchè, in questo caso specifico, un ORM è una bestia molto complessa, e consigliarlo ad uno che adesso sta cominciando con i database relazionali non è una buona cosa. Riguardo i gusti personali, gli ORM poi non mi piacciono perchè li reputo una astrazione sbagliata sopra il modello relazionale. [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
Il 16/02/2014 14:04, Manlio Perillo ha scritto: Perchè, in questo caso specifico, un ORM è una bestia molto complessa, e consigliarlo ad uno che adesso sta cominciando con i database relazionali non è una buona cosa. Ciao, sto seguendo con interesse ma il livello si è alzato un po' ;) Cerco di spiegarvi cosa vorrei fare. Per adesso si tratta di una piccola applicazione per tener traccia di accessi e pagamenti per una associazione. Scenario: Qualche centinaio di utenti avranno una carta RFID (codice univoco) con la quale potranno accedere alla sala dell'associazione. Ad ogni codice nel db corrisponderà l'anagrafica, numeri di telefono ecc, una decina di cose specifiche dell'associazione. Oltre a questo, ogni ingresso/uscita andrebbe immagazzinato da qualche parte. All'ingresso vi sarà anche un controllo se l'utente è in regola con i pagamenti delle quote associative. Gli utenti possono essere di vario tipo (studenti/Adulti/pensionati) con vari tipi di possibile associazione (mensile/annuale/n°di ingressi). Tutti i controlli verranno fatti via sw appoggiandomi ad un db (sto propendendo per mongodb... ma non sono ancora sicuro) Ho visto un po' di differenze tra db relazionali e documentali e penso che per il mio caso non faccia molta differenza quale uso. (il numero di campi sarà fisso) Anche i tempi delle varie query penso siano insignificanti in entrambi i casi visto che si parla di qualche migliaio di dati. Non mi è invece molto chiaro come posso immagazzinare tutte le date/ora degli ingressi e uscite? suggerimenti? Come facilità d'uso cosa mi consigliate? mongodb? SQLite? Dimenticavo... l'accesso al db avverrà sempre dallo stesso sw ma in due modi distinti, tramite la gui con richiesta dell'utente e, in automatico quando un utente passa la tessera con l'RFID, servirà prevedere thread per questo? Scusate se non ho chiarito prima questi punti che avrebbero potuto aiutarvi ad aiutarmi ma da non avevo proprio idea di come partire. Grazie dell'aiuto (anche di domenica) Ciao M. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 16/02/2014 14:50, Perini Matteo wrote: Il 16/02/2014 14:04, Manlio Perillo ha scritto: Perchè, in questo caso specifico, un ORM è una bestia molto complessa, e consigliarlo ad uno che adesso sta cominciando con i database relazionali non è una buona cosa. Ciao, sto seguendo con interesse ma il livello si è alzato un po' ;) Puoi tranquillamente ignorare i punti più complessi ;) Cerco di spiegarvi cosa vorrei fare. Per adesso si tratta di una piccola applicazione per tener traccia di accessi e pagamenti per una associazione. Scenario: Qualche centinaio di utenti avranno una carta RFID (codice univoco) con la quale potranno accedere alla sala dell'associazione. Ad ogni codice nel db corrisponderà l'anagrafica, numeri di telefono ecc, una decina di cose specifiche dell'associazione. Oltre a questo, ogni ingresso/uscita andrebbe immagazzinato da qualche parte. [...] Ho visto un po' di differenze tra db relazionali e documentali e penso che per il mio caso non faccia molta differenza quale uso. (il numero di campi sarà fisso) Anche i tempi delle varie query penso siano insignificanti in entrambi i casi visto che si parla di qualche migliaio di dati. Un database server come PostgreSQL offre molta flessibilità. Semplicemente lo installi su un server (magari separato da quello dove si trova il client, e gestito in modo da avere una buona sicurezza e backup); questo è uno dei vantaggi rispetto ad esempio ad SQLite. Personalmente mi allontanerei dal modello relazionale *solo* se fa differenza quale modello uso. Non mi è invece molto chiaro come posso immagazzinare tutte le date/ora degli ingressi e uscite? suggerimenti? Non mi sembra complesso. Quale problema vedi? Come facilità d'uso cosa mi consigliate? mongodb? SQLite? Devi innanzitutto distinguere tra modelli di dati. mongodb e SQLite usano modelli di dati differenti. Per una differenza tra i vari modelli, vedi le pagine di wikipedia per mongodb e PostgreSQL, in particolare: http://en.wikipedia.org/wiki/Document-oriented_database http://en.wikipedia.org/wiki/Relational_database Sono argomenti abbastanza ampi, inizia a documentarti e magari se hai dubbi chiedi. Tieni presente che sto assumendo tu voglia imparare ad usare un database. In alternativa puoi anche iniziare leggendo la parte introduttiva della documentazione di PostgreSQL o mongodb. Se ti va bene il modello relazionale, SQLite è sicuramente più semplice di PostgreSQL (e lo hai incluso in Python), ma ha diverse limitazioni. Dimenticavo... l'accesso al db avverrà sempre dallo stesso sw ma in due modi distinti, tramite la gui con richiesta dell'utente e, in automatico quando un utente passa la tessera con l'RFID, servirà prevedere thread per questo? Cosa intendi? [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 14:04 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Riguardo i gusti personali, gli ORM poi non mi piacciono perchè li reputo una astrazione sbagliata sopra il modello relazionale. A dire il vero ultimamente mi sono trovato con diversi progetti dove il problema era proprio il modello relazionale. Va detto che si tratta di un campione neppure lontanamente rappresentativo. Voglio dire anche se negli ulltmi 4 progetti 3 venivano meglio con dei NoSql (piu' naturali le costruzioni delle basi dati, piu' naturale usarle, aggiornarle, recuperare i dati rapidamente etc.) 4 progetti non bastano per dire che nel 75% dei casi sia cosi'. Facile che i prossimi 100 (se avro' la fortuna di lavorare a tanti) potrenbbero essere meglio con il relazionale. La tentazione di usare una struttura piu' nested come quella di MongoDb per fare certe cose e' sempre forte. Poi da vedere se paga o meno. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 14:50 GMT+01:00 Perini Matteo perini.mat...@gmail.com: sto seguendo con interesse ma il livello si è alzato un po' ;) Sai come finiscono ste cose, uno fa una domanda innocente (la mia sugli orm) e ne viene fuori una tavola rotonda. Pero' fa sempre bene ascoltare chi ne sa di piu', pure se, come mi sta accdendo in qualche passaggio, devi prima googlare un poco solo per avere idea vaga di cosa stiano dicendo ;) Cerco di spiegarvi cosa vorrei fare. Per adesso si tratta di una piccola applicazione per tener traccia di accessi e pagamenti per una associazione. Scenario: Qualche centinaio di utenti avranno una carta RFID (codice univoco) con la quale potranno accedere alla sala dell'associazione. Ad ogni codice nel db corrisponderà l'anagrafica, numeri di telefono ecc, una decina di cose specifiche dell'associazione. Oltre a questo, ogni ingresso/uscita andrebbe immagazzinato da qualche parte. All'ingresso vi sarà anche un controllo se l'utente è in regola con i pagamenti delle quote associative. Gli utenti possono essere di vario tipo (studenti/Adulti/pensionati) con vari tipi di possibile associazione (mensile/annuale/n°di ingressi). Tutti i controlli verranno fatti via sw appoggiandomi ad un db (sto propendendo per mongodb... ma non sono ancora sicuro) Io sapevo (ma posso sbagliarmi) che Mongo Db (che ribadisco quanto detto altrove trovo MLTO carino) era pensato per grosse moli di dati. Ho visto un po' di differenze tra db relazionali e documentali e penso che per il mio caso non faccia molta differenza quale uso. (il numero di campi sarà fisso) Cosa che porta piu' verso il relazionale, o meglio, che e' caratteristica buona per un relazionale (*). Anche i tempi delle varie query penso siano insignificanti in entrambi i casi visto che si parla di qualche migliaio di dati. Non mi è invece molto chiaro come posso immagazzinare tutte le date/ora degli ingressi e uscite? suggerimenti? Campi appositi di tipo date/time? (magari adesso mi darai del'idiota, ma possibile che non abbia capito bene la domanda). Come facilità d'uso cosa mi consigliate? mongodb? SQLite? Sono tutti facili e tutti difficili. Il mio consiglio, basato sulla mia teoria che il miglior editor/ide/linguaggio/db/etc. e' quello con cui ti trovi meglio) e' di provare entrambi, giocarci un poco e poi decidere. Dimenticavo... l'accesso al db avverrà sempre dallo stesso sw ma in due modi distinti, tramite la gui con richiesta dell'utente e, in automatico quando un utente passa la tessera con l'RFID, servirà prevedere thread per questo? Dipende da quanti user contemporaneamente accedono. Grazie dell'aiuto (anche di domenica) la domenica e' un giorno come gli altri se non sei un fanatico religioso. ;) * Per un progetto (che dorme nel cassetto da anni) avevo necessita' di tabelle che potevano avere un numero di campi variabili. Volevo pero' evitare una tabella correlata 1 a molti per motivi di performance. Ed ero ricorso ad una tabella a 4 campi (va beh, tra id autoincrementale e altri accessori erano di piu' ma quelli importanti erano 4) e per la precisione identificatore della transazione (raggruppamento) tipologia dell'oggetto nome dell'oggetto valore dell'oggetto Si tratta di una applicazione per immobiliari, il primo campo era riferito alla proposta immobiliare, il secondo mi diceva se si trattava di prezzi, tipologie di transazione, descrizione di accessori, etc, il terzo era il nome dell'oggetto in se e l'ultimo il suo valore. Con un dirty trick riuscivo ad cercare proposte immobiliari variegate (esempio offerte in affitto di appartamenti con 3 camere, 2 bagni, posto auto, riscaldamento autonomo, tra il 2ndo ed il 4to piano, non attici, in una data zona e ad un prezzo massimo di x) ma era davvero una query poco ortodossa (una sommatoria di variabili messe a 1 se caratteristica presente). Poi ho scoperto MongoDb e tutto e' stato rivisitato in maniera naturale. Pero' e' un caso specifico dove la stessa proprieta' immobiliare puo' presentare un range di caratteristiche di cui alcune comuni (prezzo, indirizzo, tipologia), altre specifiche del tipo (un garage non avra' ascensore o giardino) ed altre ancora magari presenti solo per quella proposta (un appartamento con giardino pensile per dire). Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 16/02/2014 15:27, Carlos Catucci wrote: 2014-02-16 14:04 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com mailto:manlio.peri...@gmail.com: Riguardo i gusti personali, gli ORM poi non mi piacciono perchè li reputo una astrazione sbagliata sopra il modello relazionale. A dire il vero ultimamente mi sono trovato con diversi progetti dove il problema era proprio il modello relazionale. Nulla di male, ma ORM significa Object *Relational* Mapper :) Quindi sospetto tu abbia quotato la parte sbagliata del mio messaggio. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 16:01 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Nulla di male, ma ORM significa Object *Relational* Mapper :) Quindi sospetto tu abbia quotato la parte sbagliata del mio messaggio. Perdonami, avevo deviato, dall'ORM in se ai modelli in generale, discorso ripreso poi. Sebbene molti ORM supportino dei NoSql (Django almeno mi sembra lo faccia con MongoDb) Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 02/16/2014 03:41 PM, Carlos Catucci wrote: Io sapevo (ma posso sbagliarmi) che Mongo Db (che ribadisco quanto detto altrove trovo MLTO carino) era pensato per grosse moli di dati. Dalla mia esperienza, non riesco a capire quale sia l'esatta collocazione di MongoDB. E questo perche`, sempre nell'ottica di fargli gestire grosse moli di dati, devi avere una configurazione che richiede almeno 9 (nove!) nodi del database NoSQL. Di contro, con PostgreSQL mi basta una istanza per avere prestazioni comparabili Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 17:39 GMT+01:00 Enrico Bianchi enrico.bian...@ymail.com: Dalla mia esperienza, non riesco a capire quale sia l'esatta collocazione di MongoDB. E questo perche`, sempre nell'ottica di fargli gestire grosse moli di dati, devi avere una configurazione che richiede almeno 9 (nove!) nodi del database NoSQL. Di contro, con PostgreSQL mi basta una istanza per avere prestazioni com Io trovo comoda la struttura json delle tabelle e il fatto che non abbia tabelle rigide. Per certi progetti ovvio. Ma non sono un esperto. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 02/16/2014 05:42 PM, Carlos Catucci wrote: Io trovo comoda la struttura json delle tabelle e il fatto che non abbia tabelle rigide. 'Sta cosa poteva avere senso prima del 2012, ovvero prima dell'avvento di PostgreSQL 9.2, dove per la prima volta sono comparsi i campi JSON. Ad oggi, nessuno ti vieta di avere una tabella con un solo campo JSON e navigarla cosi`: SELECT json-accessi FROM tabella WHERE json-uid = 1 Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 18:39 GMT+01:00 Enrico Bianchi enrico.bian...@ymail.com: 'Sta cosa poteva avere senso prima del 2012, ovvero prima dell'avvento di PostgreSQL 9.2, dove per la prima volta sono comparsi i campi JSON. Ad oggi, nessuno ti vieta di avere una tabella con un solo campo JSON e navigarla cosi`: SELECT json-accessi FROM tabella WHERE json-uid = 1 Vero, infatti mi hanno detto che PG abbia anche prestazioni superiori. Ah, poter avere tempo di studiare a fondo tutto. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 02/16/2014 02:50 PM, Perini Matteo wrote: Tutti i controlli verranno fatti via sw appoggiandomi ad un db (sto propendendo per mongodb... ma non sono ancora sicuro) Te lo sconsiglio, non tanto per la mole dei dati (irrisoria, stiamo parlando di una decina di Mb all'anno), ma perche` non ti da nessun vantaggio evidente rispetto ad un RDBMS Ho visto un po' di differenze tra db relazionali e documentali e penso che per il mio caso non faccia molta differenza quale uso. (il numero di campi sarà fisso) Non e` la variabilita` dei campi a fare la differenza, ma la mappatura fra di loro. In un RDBMS e` fissa, in un Document Store e` variabile Non mi è invece molto chiaro come posso immagazzinare tutte le date/ora degli ingressi e uscite? suggerimenti? I RDBMS usano tipi di dati ad hoc, che ti permettono anche di eseguire operazioni su di loro. In alternativa, converti tutto in epoch e salvali in quel formato Come facilità d'uso cosa mi consigliate? mongodb? SQLite? Posto che facilita` d'uso in questo caso e` altamente improprio, ti consiglio di rimanere su PostgreSQL o su Firebird, in virtu` di come intendi procedere (e.g. su PostgreSQL hai piu` funzionalita`, su Firebird hai la manutenzione tendente allo zero) Dimenticavo... l'accesso al db avverrà sempre dallo stesso sw ma in due modi distinti, tramite la gui con richiesta dell'utente e, in automatico quando un utente passa la tessera con l'RFID, servirà prevedere thread per questo? Secondo me devi necessariamente prevedere due applicativi distinti, uno in ascolto costantemente sul db (ci sono delle metodologie su PostgreSQL che ti permettono di farlo senza fare polling continuo), l'altro che si connette solo quando serve (ovvero quando apro la gui) Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 12:33 GMT+00:00 Diego Barrera diegonebarr...@yahoo.it: On 16/02/2014 12:40, enrico franchi wrote: L'architettura del db deve essere *sempre* il piu' efficiente possibile. Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'. Alla luce di questo e avendo in mente che devo andare in produzione il prima possibile, (leggi per ora mi interessa poco scalare, ma mi server avere una killer app per vedere come va) che succede se opero in questo modo: 1. creo model e tutta app con l'orm; 2. l'app funziona e ho tanti clienti: primi problemi a scalare 3. ottimizzo sql e impostazioni specifiche dbms Mi sembra un buon compromesso. Se le cose funzionano veramente cosi', certo. Solo che nella pratica non succede cosi'. Succede che fra il punto 2 e il punto 3 ci sono anche le nuove features, i bug fix, vari cazzi architetturali non previsti, tutta quella parte di operations che non sapevi che esistesse e che ti devi inventare, cominciare a mettere su team di risposta alle emergenze... Quindi tipicamente quello che fai al posto del 3 e' infilare un po' di patch, fare un po' di porcate con memcache etc etc etc. Dalla strada arrivano notizie di tutti i tipi. C'e' twitter che riscrive tutto in Scala da Ruby. Ci sono quelli che invece falliscono perche' un competitor, sebbene arrivato secondo sul mercato, ci arriva con un prodotto che funziona *anche* sotto scala e gli utenti migrano in massa. Ci sono quelli che vanno avanti a zoppicare per anni e nessuno dice nulla. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 14:27 GMT+00:00 Carlos Catucci carlos.catu...@gmail.com: A dire il vero ultimamente mi sono trovato con diversi progetti dove il problema era proprio il modello relazionale. Va detto che si tratta di un campione neppure lontanamente rappresentativo. Voglio dire anche se negli ulltmi 4 progetti 3 venivano meglio con dei NoSql (piu' naturali le costruzioni delle basi dati, piu' naturale usarle, aggiornarle, recuperare i dati rapidamente etc.) 4 progetti non bastano per dire che nel 75% dei casi sia cosi'. Facile che i prossimi 100 (se avro' la fortuna di lavorare a tanti) potrenbbero essere meglio con il relazionale. La tentazione di usare una struttura piu' nested come quella di MongoDb per fare certe cose e' sempre forte. Poi da vedere se paga o meno. Che dire... non sapendo le specifiche e' difficile parlarne. Il fatto e' che su molti nosql e' semplicemente piu' facile vomitare dati nella base di dati e tirarli fuori. Tutto questo e' molto semplice (perche' quasi non ti preoccupi del design della parte di persistenza). Poi quando le cose cominciano a rompersi, e' un flagello. Quando cominciano a finire dentro dati fatti troppo male e tu lo scopri qualche mese dopo, generalmente quando hai rimosso i log che ti avrebbero detto perche', e tipicamente alle quattro di mattina di sabato, quando ti suona il pager, e tu hai un hangover terrificante... Poi niente da dire, ci sono molti casi d'uso in cui il modello relazionale non e' particolarmente indicato. Diciamo che di solito le cose semplici spesso nascondono la complessita' da qualche altra parte. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 20:15 GMT+01:00 enrico franchi enrico.fran...@gmail.com: Poi niente da dire, ci sono molti casi d'uso in cui il modello relazionale non e' particolarmente indicato. Diciamo che di solito le cose semplici spesso nascondono la complessita' da qualche altra parte. Sintesi perfetta. C'e' da dire che come economia di scala io viaggio in ordini di grandezza di certo abbatsanza piccoli da non dover scalare molto o spesso. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 16/02/2014 20:10, enrico franchi wrote: Se le cose funzionano veramente cosi', certo. Questo gia' potrebbe bastare :D Dalla strada arrivano notizie di tutti i tipi. C'e' twitter che riscrive tutto in Scala da Ruby. Ci sono quelli che invece falliscono perche' un competitor, sebbene arrivato secondo sul mercato, ci arriva con un prodotto che funziona *anche* sotto scala e gli utenti migrano in massa. Ci sono quelli che vanno avanti a zoppicare per anni e nessuno dice nulla. Spero di essere dell'ultimo tipo ;) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] python SQL?
Ciao a tutti, mi trovo ad affrontare la mia prima applicazione che fa uso di database. Quale mi consigliate? E' da un po' che seguo questa lista e mi sembra che quasi tutti siate orientati verso PostgreSQL... sbaglio? Ho anche dato un occhiata in giro per vedere che libreria usare e ne ho viste di molti tipi. Psycopg1, Psycopg2, bpgsq ? Accetto qualsiasi consiglio considerate anche che è il mio primo approccio ai db ma che potrei averne bisogno anche in futuro. Grazie Ciao M. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
Ciao Matteo, On Saturday 15 Feb 2014 15:20:17 Perini Matteo wrote: Ciao a tutti, mi trovo ad affrontare la mia prima applicazione che fa uso di database. Quale mi consigliate? E' da un po' che seguo questa lista e mi sembra che quasi tutti siate orientati verso PostgreSQL... sbaglio? Dipende un po' da cosa devi fare, se è sempre per l'applicazione con RFID, forse potresti optare anche per qualcosa non SQL tipo MongoDB: http://api.mongodb.org/python/current/tutorial.html Ciao Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
Il 15/02/2014 15:48, Pietro Zambelli ha scritto: Dipende un po' da cosa devi fare, se è sempre per l'applicazione con RFID, Si forse potresti optare anche per qualcosa non SQL tipo MongoDB: http://api.mongodb.org/python/current/tutorial.html Grazie Pietro... mentre guardo meglio il link mi sapreste dire che differenza c'è tra un db SQL e un altro? Solo il linguaggio? Potenzialità, limiti? Grazie Ciao M. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-15 15:48 GMT+01:00 Pietro Zambelli peter.z...@gmail.com: Dipende un po' da cosa devi fare, se è sempre per l'applicazione con RFID, forse potresti optare anche per qualcosa non SQL tipo MongoDB: http://api.mongodb.org/python/current/tutorial.html Ripasso quanto mi hanno detto: Postgres gestisce tabelle NoSql MEGLIO di gran parte dei NoSql nativi. La fonte e' affidabile, io pero' ancora non ho provato. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
Ciao Matteo, ti consiglio di usare SQLite: http://www.sqlite.org/ http://docs.python.org/2/library/sqlite3.html Dal tuo post non si capisce perche' SQL sia essenziale. Nel caso non lo fosse ti consiglio questi DBMS: * MongoDB http://www.mongodb.org/ , * UnQLite promette bene: http://unqlite.org/ https://pypi.python.org/pypi/unqlitepy ciao, -Francesco 2014-02-15 15:20 GMT+01:00 Perini Matteo perini.mat...@gmail.com: Ciao a tutti, mi trovo ad affrontare la mia prima applicazione che fa uso di database. Quale mi consigliate? E' da un po' che seguo questa lista e mi sembra che quasi tutti siate orientati verso PostgreSQL... sbaglio? Ho anche dato un occhiata in giro per vedere che libreria usare e ne ho viste di molti tipi. Psycopg1, Psycopg2, bpgsq ? Accetto qualsiasi consiglio considerate anche che è il mio primo approccio ai db ma che potrei averne bisogno anche in futuro. Grazie Ciao M. ___ 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] python SQL?
Il 15/02/2014 15:55, Francesco Stablum ha scritto: ti consiglio di usare SQLite: http://www.sqlite.org/ http://docs.python.org/2/library/sqlite3.html Dal tuo post non si capisce perche' SQL sia essenziale. Dovete perdonarmi ma sono completamente niubbio sul tema... ho sempre sentito parlare dei db che ho citato sopra ma sto cominciando adesso a farmi un idea. Userò, almeno all'inizio, il db solo in locale e solo da python con esportazione in csv (o simili). Nel caso non lo fosse ti consiglio questi DBMS: * MongoDB http://www.mongodb.org/ , * UnQLite promette bene: http://unqlite.org/ https://pypi.python.org/pypi/unqlitepy Ora guardo mongodb che mi sembra, per quello che devo fare, la soluzione migliore... poi arriverò con un sacco di altre domande. Sono comunque sempre ben accetti consigli, spiegazioni, suggerimenti. Grazie Matteo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 02/15/2014 03:54 PM, Carlos Catucci wrote:
Ripasso quanto mi hanno detto: Postgres gestisce tabelle NoSql MEGLIO
di gran parte dei NoSql nativi.
+1
A supporto di cio`, su di un HP MicroServer N54L con dischi Sata in RAID
10 e 2Gb di RAM ('nammerda) una tabella con un solo campo JSON
contenente 13 milioni di record ù850Gb di file di testo, per fare un
paragone) estrae un campo JSON indicizzato (si, puo` essere fatto senza
problemi) in 10 secondi la prima volta e in meno di un secondo la
seconda. Gli stessi dati su MongoDB mandavano a donnine una macchina con
64Gb di RAM (hint: MongoDB e` memory mapped ed e` performante solo se lo
si fa scalare in sharding)
Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 02/15/2014 03:20 PM, Perini Matteo wrote: mi trovo ad affrontare la mia prima applicazione che fa uso di database. Quale mi consigliate? Dire quale database uso senza sapere cosa fa l'applicazione e` come dire che martello uso senza sapere cosa si deve inchiodare. Per capirci: - Hai piu` connessioni ai dati contemporaneamente? - Il database deve essere legato all'applicazione? - Quali operazioni sono piu` ricorrenti? (e questo e` solo il minimo di domande che mi viene in mente) Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 02/15/2014 06:50 PM, Enrico Bianchi wrote: ù850Gb di file di testo, per fare un paragone) -_- Correggiamo ed ampliamo questo typo: il file di testo e` di 50Gb, su PostgreSQL (9.3) viene una tabella di 19Gb, a cui devono essere aggiunti 3Gb di dati TOAST e 400Mb di indici, il resto rimane quello che ho detto Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
On 15/02/2014 15:20, Perini Matteo wrote: Ciao a tutti, mi trovo ad affrontare la mia prima applicazione che fa uso di database. Quale mi consigliate? E' da un po' che seguo questa lista e mi sembra che quasi tutti siate orientati verso PostgreSQL... sbaglio? Con PostgreSQL è raro sbagliare. In casi speciali ci sono comunque alternative; ad esempio se non vuoi avere un database server separato (che deve essere gestito) c'è SQLite. Ma SQLite ha anche molte limitazioni, se confrontato con un database serio come PostgreSQL. Ho anche dato un occhiata in giro per vedere che libreria usare e ne ho viste di molti tipi. Psycopg1, Psycopg2, bpgsq ? psycopg2, oppure sqlalchemy (ma senza l'ORM, solo sqlalchemy.sql) per facilitare la scrittura di alcune query, come le INSERT. Accetto qualsiasi consiglio considerate anche che è il mio primo approccio ai db ma che potrei averne bisogno anche in futuro. Impara PostgreSQL (la documentazione è molto buona), così almeno quando ti serviranno altri database avrai un termine di paragone solido. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-15 19:56 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: ma senza l'ORM, solo sqlalchemy.sql Per curiosita' da ignorante, ma perche' non l'ORM? Non ti piaciono gli orm o e' un qualcosa di SQLAllchemy in particolare che non va? Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-15 19:55 GMT+00:00 Carlos Catucci carlos.catu...@gmail.com: Non ti piaciono gli orm +1 -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] python SQL?
2014-02-16 1:54 GMT+01:00 enrico franchi enrico.fran...@gmail.com: Non ti piaciono gli orm +1 De gustibus non disputandum est. Io personalmente li trovo comodi. Il non dover impazzire tra dialetti, il poter svilupppare in locale, per dire, su Sqlite e poi andare in produzione con Postgres, cosa che mi facilita di molto le cose (per dirne una se aggiungo dati di test alla base dati un push sul repo condiviso (*) rende disponibile la cosa a tutti i coinvolti nel progetto senza dover eseguire un dump da allegare e un db_restore dopo un pull) senza impazzire sui dialetti e sulle varie differenze (sacrosante, ciascun Db ha il suo motivo di esistere, di essere specializzato in qualcosa, tranne forse un paio). Poi ovvio che se devo fare una query particolarmente incasinata (e accade SOLO se lavoro su basi dati esistenti, in caso contrario se e' roba mia parto dal presupposto di avere sbagliato l'architettura e riprogetto di conseguenza) posso usrae una raw, ma deve essere davvero un caso limite dove l'ORM non ce la fa. Lo so, mi direte che l'ORM non ottimizza come puo' fare una query scritta ad hoc, ma a volte la flessibilita' conta piu' delle prestazioni. Carlos -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
