Verwenden von PouchDB mit SQL Server und CouchDB

Question

Ich weiß, dass PouchDB nur mit CouchDB kompatiblen Servern funktioniert. Gibt es eine Möglichkeit, SQL Server als Back-End zu verwenden, während das ursprüngliche Schema beibehalten wird?

Ich habe einen Gedanken, wie dies zu erreichen ist, aber ich bin mir nicht ganz sicher, ob es machbar ist. Jede Antwort, die dies zum Erfolg führt, wird geschätzt.

Die Art, wie ich es sehe, ist, CouchDB zu verwenden, um die Sync-Metadaten wie Revisionen und alle Dinge zu speichern, die für eine erfolgreiche Synchronisierung benötigt werden. Die aktuellsten Daten werden dann auf dem SQL Server nach dem ursprünglichen Schema gespeichert.

Um dies zu erreichen, muss ich einen CouchDB-kompatiblen Server mit meinem Stack, der C# ist, erstellen. Dies funktioniert wie ein Proxy zwischen CouchDB und PouchDB, so dass ich nicht wirklich alle Methoden implementieren muss. Ich muss bestimmte Methoden abfangen, die es mir ermöglichen, SQL Server und CouchDB synchron zu halten (nach Geschäftsregeln) und gleichzeitig die Synchronisierungsfunktion von CouchDB über die SQL Server-Daten zu nutzen. Damit könnte ich auch einen Haufen Middleware hinzufügen, die ich mir in Zukunft wünsche.

Ist dieses Ding machbar? Ich weiß, dass express-pouchdb existiert, aber es ist nur ein CouchDB-kompatibler Server mit einem PouchDB-Backend. Ich wollte, dass CouchDB und SQL Server zusammenarbeiten. Wenn ja, wie soll ich vorgehen?

Answer 1

Klingt vielleicht nach einer verrückten Idee, aber Sie können PouchDB auf dem Server verwenden und einen alternativen Speicheradapter anschließen, der SQL Server verwendet. Auf diese Weise müssen Sie die Replikationslogik nicht neu implementieren (das ist wirklich schwierig), Sie können sich auf den Speicherbereich konzentrieren.

Einige Hinweise:

• https://pouchdb.com/adapters.html
• https://github.com/Level/leveldown
• https://github.com/calvinmetcalf/sqldown

Answer 2

Sie könnten auf der _changes API von CouchDB eine serverseitige Hörer-Setup. Diese API ermöglicht es dem Server, einen Change-Listener-Prozess auszuführen, der ausgelöst wird, wenn Daten in CouchDB geändert werden. Durch Überprüfen der Änderungsliste (docs) und des Typs der Änderung ist es möglich, das JSON-Dokument (oder Teile davon), das in SQL gespiegelt werden soll, mit einer benutzerdefinierten Logik zuzuordnen.

Die Zuordnung von JSON zu relationalen Tabellen kann je nach Schema schwierig sein. Die Komplexität kann reduziert werden, indem nur die Daten zugeordnet werden, die als relational gespeichert werden sollen. Nennen Sie es einen hybriden Ansatz. Zum Beispiel könnten Kundendefinitionen in CouchDB schemalos bleiben (wodurch der Vorteil von schemalosen Inhalten erhalten bleibt), aber Verkaufswerbebuchungen könnten für einfachere Berichtszwecke in SQL gespiegelt werden. Wahrscheinlich gibt es nur bestimmte Daten, die in SQL Server wirklich sinnvoll sind. Couchdb ist deine Quelle der Wahrheit.

Sie haben nach dem SQL-Schema gefragt. In Wirklichkeit wollen oder wollen Sie das SQL-Schema höchstwahrscheinlich nicht vollständig pflegen. Unter Verwendung des obigen Ansatzes interessiert es Sie wahrscheinlich nicht in SQL, wenn sich die Adresse eines Kunden ändert; Das Kundenschema bleibt in CouchDB flexibel. Sie können jedoch einen SQL-Eintrag für die Kunden-ID (nur) erstellen, um die referenzielle Integrität zu erzwingen und den Fall zu behandeln, wenn der Kunde gelöscht wird.

Die Änderungen können ab einem bestimmten Zeitpunkt wiederholt werden, um den Fehler zu beheben.

Zum Vergleich:

http://guide.couchdb.org/draft/notifications.html