# Mongodb **URL:** \ **Category:** IT\ **Created:** [May 8, 2012, 5:33pm UTC](https://www.ruby-forum.com/t/mongodb/219601 "2012-05-08T17:33:53Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Gurdipe\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/b77776/32.png) [@Gurdipe\_D](https://www.ruby-forum.com/u/Gurdipe_D)\ **Post date:** [May 8, 2012, 5:33pm UTC](https://www.ruby-forum.com/t/mongodb/219601/1 "2012-05-08T17:33:53Z")
Salve. Qualcuno ha felicemente lasciato definitivamente i classici db relazionali come postgres per lanciarsi nel mondo del NOSQL utilizzando db come mondodb? Devo sviluppare un’app di gestione ditte: ciascuna ditta ha un’attivita’ commerciale in varie forme: negozio, ecommerce, corrispondenza, ecc. e di ciascuna di queste attivita’ commerciali devo tenere un history, sapere quando sono state attivate, quando e se sono state cessate, i vari passaggi volture, subingressi, ecc. Stavo iniziando il progetto con postgresql che uso sempre ma noto, da letture in rete, che i db detti NOSQL, stanno prendendo sempre piu’ piede. Che ne pensate? ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 5:41pm UTC](https://www.ruby-forum.com/t/mongodb/219601/2 "2012-05-08T17:41:58Z")
> Che ne pensate? Penso che buttare via un signor database come Postgres, che va benissimo per dei dati strutturati, dove sicuramente hai bisogno di tracciare i rapporti fra le varie componenti (join!) per un database sperimentale non sia il massimo. Il bello dell’informatica e` che ci sono sempre cose nuove e interessanti da imparare, ma per quanto riguarda i nosql, punterei di piu` su qualcosa come redis come sostegno/appoggio nel momento quando ti rendi conto che Postgres ha bisogno di qualcosa in piu`. [http://www.mongodb-is-web-scale.com/](http://www.mongodb-is-web-scale.com/) Io ho avuto a che fare con MongoDB lo scorso anno, e non mi e` piaciuto molto: dovendo fare dei query un po' piu` “complessi”, diventava molto lento. E i numeri nel DB (migliaia di record) erano numeri che Postgres gestisce senza fatica. Hanno usato Mongo per provare una cosa nuova… – David N. Welton > **[David N. Welton](https://www.welton.it/davidw/)** [http://www.dedasys.com/](http://www.dedasys.com/) ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 5:44pm UTC](https://www.ruby-forum.com/t/mongodb/219601/3 "2012-05-08T17:44:26Z")
Qui, imho, uscir un flame. Io sono della opinione di David, che mi ha preceduto di pochi minuti. “does /dev/null support sharding? :-)” 2012/5/8 David W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 5:46pm UTC](https://www.ruby-forum.com/t/mongodb/219601/4 "2012-05-08T17:46:56Z")
Non si “lascia” nessuno strumento, si usa quello giusto. I database NoSQL non sono “i nuovi database”, ma DEI nuovi database con delle caratteristiche precise. NoSQL is not the same thing as no SQL 🙂 2012/5/8 Stefano P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 5:54pm UTC](https://www.ruby-forum.com/t/mongodb/219601/5 "2012-05-08T17:54:24Z")
Il 08/05/12 17:44, Stefano P. ha scritto: > Qui, imho, uscir un flame. Supporto la nascita del flame, cos la volta buona che capisco quando usare noSQL! 🙂 ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 5:50pm UTC](https://www.ruby-forum.com/t/mongodb/219601/6 "2012-05-08T17:50:43Z")
Qui ci sono delle slide e se cerchi c’é anche un video che parla di perché hanno migrato Diaspora da MongoDB a Mysql. > **[Taking Diaspora from MongoDB to MySQL (RubyConf 2011)](https://www.slideshare.net/sarahmei/taking-diaspora-from-mongodb-to-mysql-rubyconf-2011)** > > 1 Image copyright Yukihiro Matsumoto MongoDB
to
MySQL 2 Image copyright Yukihiro Matsumoto MongoDB
to
MySQL ... Il problema in generale è che molte tecnologie “moderne” servono per gestire meglio dei casi di nicchia specifici piuttosto che per rimpiazzare a 360 un db classico. Luigi ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 6:00pm UTC](https://www.ruby-forum.com/t/mongodb/219601/7 "2012-05-08T18:00:37Z")
Il giorno 08/mag/2012, alle ore 17:33, Mauro ha scritto: > Stavo iniziando il progetto con postgresql che uso sempre ma noto, da > letture in rete, che i db detti NOSQL, stanno prendendo sempre piu’ > piede. > Che ne pensate? Che hai un classico caso di progetto dove e’ richiesto (per vari motivi) il modello “relazionale” (o qualcosa che ci si avvicini molto). Qui NOSQL ci azzecca poco, ma di sicuro tieni d’occhio questo mondo, alcuni prodotti risolvono problemi ben specifici (che magari il tuo applicativo potrebbe avere). Personalmente uso molto mongodb e redis. Il primo quando ho bisogno di gestire dati schema-free (il cms locomotive e’ secondo me l’esempio migliore di questo utilizzo), il secondo per le code e la gestione di liste e set. – Roberto De Ioris > **[unbit - Overview](https://github.com/unbit)** > > makers of uWSGI and many more open source projects - unbit JID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 5:59pm UTC](https://www.ruby-forum.com/t/mongodb/219601/8 "2012-05-08T17:59:23Z")
> Supporto la nascita del flame, cos la volta buona che capisco quando > usare noSQL! 🙂 Quando devi fare qualcosa che un DB tradizionale non fa molto bene. – David N. Welton > **[David N. Welton](https://www.welton.it/davidw/)** [http://www.dedasys.com/](http://www.dedasys.com/) ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 6:20pm UTC](https://www.ruby-forum.com/t/mongodb/219601/9 "2012-05-08T18:20:32Z")
Complemento citando l’approccio della “polyglot persistence” > **[bliki: PolyglotPersistence](https://martinfowler.com/bliki/PolyglotPersistence.html)** > > For the last few decades, relational databases have been the automatic choice for enterprise applications. But now we have to choose a mix of databases with different strengths. ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 6:04pm UTC](https://www.ruby-forum.com/t/mongodb/219601/10 "2012-05-08T18:04:22Z")
In realt i motivi per cui hanno migrato non sono insiti nel db, ma nella loro scarsa esperienza con mongoDb, nella poca documentazione e poco supporto dalla comunit. Dopo di che o non avrei scelto mysql, ma piuttosto postgresql quindi avrei da ridire anche sulla loro migrazione. Ci sono molti ambiti in cui sia un db sql che uno NoSql possono risolvere la situazione, il problema capire quale lo fa meglio. Francesco Il 08/05/2012 17:50, Luigi M. - [grigio.org](http://grigio.org) ha scritto: ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 8, 2012, 9:42pm UTC](https://www.ruby-forum.com/t/mongodb/219601/11 "2012-05-08T21:42:10Z")
Per l’applicazione che hai descritto io sceglierei un database Postgres. Ho scelto mongodb in almeno un paio di progetti, ma c’erano presupposti diversi. Nella mia esperienza, l’euforia nell’uso di un database noSQL come mongodb presto mitigata dal dover fare i conti proprio con la struttura mancante. Voglio dire che con un database SQL ci sono pochi modi per sbagliare il disegno della base dati. E’ tutto molto comprovato, e con ActiveRecord viaggi veramente sui binari. Non la stessa cosa con un noSQL. Paradossalmente molto pi importante pensare prima alla struttura dei tuoi dati di quanto non lo sia con database SQL, almeno per quanto riguarda mongodb, in cui hai le ‘collection’ e l’atomciti negli update dei singoli documenti delle collection. Altra nota importante sono le transazioni, che se non sbaglio non sono ancora implementate con la stessa atomicit in nessun noSQL. Per concludere, non userei mai un nosql per un gestionale. Scegli lo strumento giusto per il lavoro giusto. Tra l’altro considera che se volessi sperimentare schemaless alcune parti della tua applicazione, in postgres hai almeno due modi per farlo, il data type XML e il pi recente HStore: > **[8.13. XML Type](https://www.postgresql.org/docs/current/datatype-xml.html)** > > 8.13. XML Type 8.13.1. Creating XML Values 8.13.2. Encoding Handling 8.13.3. Accessing XML Values The xml data type can be used … > **[F.18. hstore](https://www.postgresql.org/docs/current/hstore.html)** > > F.18. hstore F.18.1. hstore External Representation F.18.2. hstore Operators and Functions F.18.3. Indexes F.18.4. Examples F.18.5. Statistics F.18.6. Compatibility F.18.7. Transforms … Ho usato il datatype XML con gran soddisfazione di recente. ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 9, 2012, 9:02am UTC](https://www.ruby-forum.com/t/mongodb/219601/12 "2012-05-09T09:02:38Z")
> Per concludere, non userei mai un nosql per un gestionale. Scegli lo strumento > giusto per il lavoro giusto. Grazie, questo thread e’ stato …salutare 🙂 ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 9, 2012, 12:55pm UTC](https://www.ruby-forum.com/t/mongodb/219601/13 "2012-05-09T12:55:19Z")
Ho poco da aggiungere ma se serve una soluzione per persistere dati con struttura variabile: > **[F.18. hstore](https://www.postgresql.org/docs/9.1/hstore.html)** > > F.18. hstore F.18.1. hstore External Representation F.18.2. hstore Operators and Functions F.18.3. Indexes F.18.4. Examples F.18.5. Statistics F.18.6. Compatibility F.18.7. Transforms … ma credo che anche questo sia stato citato. Per chi e` stanco di usare le migrazioni, potrebbe passare a Datamapper, non c'e' bisogno di cambiare DB. Credo che mongodb riesca a gestire meglio piu` nodi, rispetto a postgres e mysql, anche se usa comunque il paradigma master-slave. Riak usa un circular buffer e` scala molto meglio. Comunque ci sono anche delle soluzioni per la replicazione su Mysql e soprattutto per Postgres. Per MySql uso Xeround DB ma e` su EC2 ed e` un PaaS. Un progetto di replicazione semplice e` [http://www.rubyrep.org/](http://www.rubyrep.org/) ma usa il metodo dei trigger, quindi non proponibile su piattaforme di hosting, ma utile se la app usa una sua infrastruttura. Ho letto un post contro mongodb, parlava della perdita di dati ed altri problemi derivati ad una grossa mole di dati da gestire, purtroppo non ricordo il link. ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 10, 2012, 11:27am UTC](https://www.ruby-forum.com/t/mongodb/219601/14 "2012-05-10T11:27:16Z")
a chi non l’avesse letto segnalo anche l’articolo molto interessante > **[bliki: Orm Hate](https://martinfowler.com/bliki/OrmHate.html)** > > Object-Relational Mappers get a lot of hate from people who misjudge the complexities of the task. ## Ciao, gk ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 10, 2012, 12:04pm UTC](https://www.ruby-forum.com/t/mongodb/219601/15 "2012-05-10T12:04:29Z")
Infatti, l’articolo di Martin F. porta all’attenzione il mito del fatto che gli ORM ti fanno dimenticare l’esistenza del DB. Purtroppo questo mito ha fatto danni, visto che astrarre il db non cosi semplice e nemmeno gli ORM sofisticati ci riescono. Il punto capire se database come MongoDb riescono a risolvere il problema e al momento sembra che qualcosa riescono a risolvere, ma forse presto per cantare vittoria. Per la mia seppur breve esperienza, i db nosql (parlo di mongo perch un po’ lo conosco) risolvono il problema del salvare i dati in modo semplice: prendo un grafo di oggetti e lo sparo in una collezione. Il problema nasce quando devo ricaricare i dati e andare “in join” per prendere altre informazioni. Ho capito che la cosa pi difficile quando si lavora con i nosql disegnare bene quelli che in DDD sono gli aggregati, se davvero si disegnano bene gli aggregati il 95% dei problemi scompare creando una collezione per aggregato. Siccome l’aggregato un’unita consistente posso salvarla e caricarla in autonomia senza che mi servano altre informazioni da altre collezioni. Questo vuol dire denormalizzare i dati (e a volte duplicare)…ma credete davvero che la normalizzazione completa sia cos importante? Per me non lo . Quindi io uno sguardo ai nosql lo darei e li terrei in considerazione in molti contesti… bye ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 15, 2012, 12:11pm UTC](https://www.ruby-forum.com/t/mongodb/219601/16 "2012-05-15T12:11:19Z")
Io non ho esperienza diretta anche se mi piacerebbe approfondire. Quali sono le differenze tra i relazionali ed i nosql? Queste quelle che mi vengono in mente: - scalabilità - prestazioni - ridondanza - sicurezza - integrità - utilizzo La questione cruciale è analizzare il contesto. Io non ho mai creato un gestionale che avesse bisogno di tanta scalabilità orizzontale e se mai mi capiterà mi chiederò, prima di scegliere il database, come farò a gestirla e presentarla. C’è anche la questione sicurezza o forse si tratta ormai solo di fiducia. Mi chiedo poi come venga gestita la ridondanza dei dati, nei relazionali ci pensano le join, se pur col peso che hanno. Infine l’utilizzo: devono essere accoppiati ad un orm altrimenti l’integrità dei dati può diventare un grosso problema. Activerecord però è nato sui relazionali e forse è meglio aspettare qualcosa creato ad hoc? @Emanuele DelBono Non ho capito la questione dei danni a proposito degli orm, a cosa ti riferisci? ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 15, 2012, 2:33pm UTC](https://www.ruby-forum.com/t/mongodb/219601/17 "2012-05-15T14:33:12Z")
2012/5/15 Marco M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > Io non ho esperienza diretta anche se mi piacerebbe approfondire. Quali > sono le differenze tra i relazionali ed i nosql? Queste quelle che mi > vengono in mente: > > - scalabilit > - prestazioni > - ridondanza > - sicurezza > - integrit > - utilizzo FWIW, se intendevi che queste sono possibili “dimensioni” per differenziare relazionali o no, direi che non funzionano (posso dare esempi di sql o non sql con si/no per tutti i casi). Come dimensioni per cui valutare invece chiaramente si. Per non direi che ci voglia un ORM se non si relazionali (beh a parte che sarebbe un O\*M 🙂 Io in passato ho lavorato con cassandra avendo fatto un layer DAO abbastanza classico a mano mi son trovato bene. Oltretutto activerecord+migration di default praticamente uguale a usare un database documentale: ogni tabella un lista di hash, la validazione applicativa e i riferimenti tra tabelle vengono generati senza foreign key/integrit referenziale. O cambiato qualcosa ultimamente e me lo sono perso? – twitter: @riffraff blog (en, it): www.riffraff.info [riffraff.blogsome.com](http://riffraff.blogsome.com) work: [circleme.com](http://circleme.com) ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 15, 2012, 3:56pm UTC](https://www.ruby-forum.com/t/mongodb/219601/18 "2012-05-15T15:56:38Z")
2012/5/15 Marco M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > All’atto pratico dici? Perch i primi hanno struttura fissa. Io da > quando uso rails non sfrutto pi le caratteristiche per l’integrit sul > db, ho tanti vantaggi tra cui il diretto controllo mentre se li usassi > sul db devo sempre passare da un sistemista. Ovviamente per bisogna > utilizzare rake per le operazioni batch altrimenti si avrebbero i > problemi di cui accennavo prima. Le prestazioni per sono ben diverse e > mi fermo qu che gli argomenti da discutere sarebbero tantissimi. beh, in quest’ultimo caso ci sarebbe DataMapper, di cui dovrebbe uscire la versione 2.0, se la scelta un DB Sql relazionale mi pare una scelta molto adatta. ## – Riccardo L’esperienza quello che ottieni quando, non ottieni quello che desideri. ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 15, 2012, 3:49pm UTC](https://www.ruby-forum.com/t/mongodb/219601/19 "2012-05-15T15:49:31Z")
> FWIW, se intendevi che queste sono possibili “dimensioni” per > differenziare relazionali o no, direi che non funzionano (posso dare > esempi di sql o non sql con si/no per tutti i casi). ho fatto di tutta l’erba un fascio per non perderci nei dettagli, secondo te non sono elementi che differiscono la macro categoria “nosql” dai relazionali? > Per non direi che ci voglia un ORM se non si relazionali (beh a > parte che sarebbe un O\*M 🙂 Chiedo scusa, in realtà mi stavo riferendo all’intero pacchetto rails, si è trattato di un lapsus. Senza un framework come rails che gestisce cose che normalmente si gestisce un database sarebbe difficoltoso: validazioni, dipendenze, observer (trigger) ecc. > Io in passato ho lavorato con cassandra avendo fatto un layer DAO > abbastanza classico a mano mi son trovato bene. Interessante > Oltretutto activerecord+migration di default praticamente uguale a > usare un database documentale: ogni tabella un lista di hash, la > validazione applicativa e i riferimenti tra tabelle vengono generati > senza foreign key/integrit referenziale. > O cambiato qualcosa ultimamente e me lo sono perso? All’atto pratico dici? Perchè i primi hanno struttura fissa. Io da quando uso rails non sfrutto più le caratteristiche per l’integrità sul db, ho tanti vantaggi tra cui il diretto controllo mentre se li usassi sul db devo sempre passare da un sistemista. Ovviamente però bisogna utilizzare rake per le operazioni batch altrimenti si avrebbero i problemi di cui accennavo prima. Le prestazioni però sono ben diverse e mi fermo quà che gli argomenti da discutere sarebbero tantissimi. ---
**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\ **Post date:** [May 15, 2012, 6:46pm UTC](https://www.ruby-forum.com/t/mongodb/219601/20 "2012-05-15T18:46:53Z")
Danni forse una parola spropositata, ma la mia sensazione che gli ORM sono nati con l’idea di colmare il gap tra il mondo relazionale e il mondo ad oggetti e non ci sono riusciti fino in fondo. La soluzione al problema non certo banale e l’introduzione di un ORM semplifica alcune cose e ne complica altre (performance, mapping difficili, dominio dipendentende dallo schema, compromessi). Invece i DB no-sql (sembra) che risolvano bene questo problema: ho un grafo lo “butto” nello store. Fine. Il problema disegnare bene i grafi (aggregati) per questo DDD ci aiuta molto. ema 2012/5/15 Marco M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): [Next page](https://www.ruby-forum.com/t/mongodb/219601.md?page=2)