2014-02-16 19:49 GMT+00:00 Diego Barrera :
> Se le cose funzionano veramente cosi', certo.
>>
> Questo gia' potrebbe bastare :D
Eh, ma non ci conterei... quello e' il fatto.
--
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://li
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 arriva
2014-02-16 20:15 GMT+01:00 enrico franchi :
> 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 com
2014-02-16 14:27 GMT+00:00 Carlos Catucci :
>
> 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 veni
2014-02-16 12:33 GMT+00:00 Diego Barrera :
> 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 pr
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 d
2014-02-16 18:39 GMT+01:00 Enrico Bianchi :
> '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
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 t
2014-02-16 17:39 GMT+01:00 Enrico Bianchi :
> 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.
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`, se
2014-02-16 16:16 GMT+01:00 Carlos Catucci :
> Sebbene molti ORM supportino dei NoSql (Django almeno mi sembra
> lo faccia con MongoDb)
>
No, l'ORM di Django non lo supporta ma c'è un fork che lo fa:
http://django-nonrel.org/
Ciao
--
M.
http://2014.djangovillage.it/ :: http://tinkergarage.it/
__
2014-02-16 16:01 GMT+01:00 Manlio Perillo :
> 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 support
On 16/02/2014 15:27, Carlos Catucci wrote:
2014-02-16 14:04 GMT+01:00 Manlio Perillo 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
2014-02-16 14:50 GMT+01:00 Perini Matteo :
> 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
a
2014-02-16 14:04 GMT+01:00 Manlio Perillo :
> 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.
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 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
On 15/02/2014 20:55, Carlos Catucci wrote:
2014-02-15 19:56 GMT+01:00 Manlio Perillo 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?
per cose piccole, SQLite
Il giorno 16 febbraio 2014 13:33, Diego Barrera
ha 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 qu
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
2014-02-16 7:51 GMT+00:00 Carlos Catucci :
>
> 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
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ì cer
2014-02-16 10:15 GMT+01:00 Daniele Tricoli :
> ... 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
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 leg
2014-02-16 1:54 GMT+01:00 enrico franchi :
> 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
2014-02-15 19:55 GMT+00:00 Carlos Catucci :
> Non ti piaciono gli orm
+1
--
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
2014-02-15 19:56 GMT+01:00 Manlio Perillo :
> 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.
_
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
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 q
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
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
contene
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 de
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/
2014-02-15 15:48 GMT+01:00 Pietro Zambelli :
> 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 tab
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
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?
Di
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
37 matches
Mail list logo
