Mix di MySQL e Mongodb in un'applicazione

Question

Sto scrivendo un'applicazione Web utilizzando PHP/Symfony2/Doctrine2 e sto semplicemente terminando la progettazione del Database. Dobbiamo importare questi oggetti (ad esempio progetti, fornitori) nel nostro database che provengono da diversi clienti con una varietà di campi. Alcuni clienti hanno 2 campi nell'oggetto del progetto e alcuni ne hanno 20. Quindi stavo pensando di implementarli in MongoDB poiché sembra un buon uso per questo.

Symfony2 supporta sia ORM che ODM, quindi non dovrebbe essere un problema, ora la mia domanda è come garantire l'integrità dei dati in entrambi i database. Perché gli oggetti nel mio MySQL db devono essere collegati in qualche modo agli oggetti in MongoDB per problemi di integrità.

Ci sono soluzioni migliori là fuori? Qualsiasi aiuto/pensieri sarebbe apprezzato

Answer 1

Bulat implementato un'estensione Dottrina mentre eravamo a OpenSky per la gestione di riferimenti tra documenti MongoDB e record di MySQL, che è attualmente seduti nelle loro (certamente obsoleto) fork del progetto DoctrineExtensions. Avrai voglia di guardare i rami orm2odm_references o openskyfork. Affinché questo sia utilizzabile nel tuo progetto, probabilmente vorrai portarlo su un nuovo fork di DoctrineExtensions, o semplicemente incorporare il codice nella tua applicazione. Sfortunatamente, non c'è documentazione a parte il codice stesso.

Per fortuna, c'è anche cookbook article sul sito Web di Doctrine che descrive come implementare questo da zero. Fondamentalmente, ci si basa su un listener di eventi per sostituire la proprietà con un riferimento (ovvero oggetto Proxy non inizializzato) dall'altro gestore oggetti e il comportamento naturale degli oggetti Proxy da caricare pigramente si prende cura del resto. Se il listener di eventi è un servizio, è possibile iniettare facilmente sia gli object manager ORM che ODM.

L'unica integrità garantita da questo modello è che si riceveranno delle eccezioni quando si tenta di idratare un riferimento errato, che è probabilmente più di quanto si otterrebbe semplicemente memorizzando un ID dell'altro database e interrogando manualmente.

Answer 2

Quindi il modo in cui abbiamo risolto questo problema è stato il passaggio a Postgres. Postgres ha un tipo di dati chiamato hstore che funziona come una colonna NoSQL. Funziona piuttosto dolce

UPDATE

Ora che sto guardando indietro, andare con jsonb invece di json o hstore in quanto permette di avere più di una struttura di dati di un negozio di valori-chiave.