问题
I am building a web application where the client needs browser access to data storage while offline. I'm thinking of using either a Firebase or PouchDB database to achieve this inside the application.
However, for the back-end I am using SQL Server. Can I synchronize the data from Firebase/PouchDB over to ms sql server engine and store it persistently? Will MS SQL Server's JSON support allow me to do this or am I wasting my time going down this route? The application is being written using Node.JS
Any help/advice would be great.
回答1:
PouchDB is a great choice for offline support! You should provide a server-side equivalent, though, so PouchDB can play its real strength: replication. Use CouchDB (stable and proven, the battle-tested "original"), IBM Cloudant (compatible DB as a service) or PouchDB Server (the new kid on the block, an implementation of CouchDB in JavaScript, still young).
You might then try to get the data from CouchDB into SQL Server, but your source of truth should always be CouchDB, as there are too many architectural differences between the two databases. Writing documents to CouchDB is just like an API call, so I suggest to give CouchDB a try!
回答2:
PouchDb Server has support for LevelUp, which allows you to swap-out the backend server for something else. Some SQL databases are supported (such as MySQL and Postgres) but I don't think SQL Server is one of them.
If you were prepared to consider an alternative SQL solution, you should be able to have a local PouchDb database and replicate it with the SQL database via PouchDb Server. I have not tried this though!
回答3:
Using MSSQL <-> CouchDB <-> PouchDB method has some serious advantages and disadvantages. I've just completed migrating part of our app to this approach, and I'll outline what I've found.
We are syncing about 400K records across 80 tables (old method), and about 6000 rows across 3 tables (new method).
Old method: MSSQL <-> REST API <-> SQLite (Mobile)
- Custom API written in PHP
- Occasional sync conflicts handled by 'whoever saved last'.
- About 20K-40K rows per second speed of save onto mobile.
- Various glitches due to my custom written sync portion on the mobile side. (writing stable sync software has a lot of hidden challenges)
New method: MSSQL <-> CouchDB <-> PouchDB <-> LokiJS
- Tested on small subset of data (6000 rows), only one portion of the app.
- PouchDB is using the IndexedDB adapter. (Will test the SQLite native adapter next)
- MSSQL -> CouchDB happens every 20 seconds or so (query).
- CouchDB -> MSSQL happens any time there is a change in CouchDB (changes feed).
- CouchDB <-> PouchDB is very stable! And slow (about 300 rows/second)!
- PouchDB itself is horribly slow to query even with indexes, compared to native SQLite. We are talking about 10 seconds for a query of 5000 records or so, vs a couple milliseconds in SQLite.
- I use LokiJS for just the query part. Speed almost matches SQLite. This means keeping LokiJS up-to-date via the PouchDB changes feed, which seems to fail occasionally when app restores from locked phone, or from a background process.
- When PouchDB resumes syncing (say you just opened the app, or re-opened it from the background), it takes a while to catch up. It seems to sync around 300 or so rows a second on a good day. Sometimes this sync starts 5-15 seconds after the app starts, which means the user may not be looking at the latest data. Once the sync is running, depending on how long it's been offline, the user could be "stuck" for a minute or so while PouchDB catches up.
- Once PouchDB is caught up, the changes feed works like magic, and any change made on any of our mobile devices is instantly pushed to CouchDB, then to all the other devices (and our server). I wrote the UI so that it updates based on the change, this giving everyone the latest info. This part does work quite well.
Advantages of CouchDB & PouchDB in my setup
- The stability of CouchDB & PouchDB syncing.
- Storing the records as JSON makes them little easier to work with in javascript.
Disadvantages of CouchDB & PouchDB
- The speed of the syncing any more than a few records is slow.
- The speed of PouchDB queries is slow (compared to native SQLite).
- PouchDB changes feed seems to hiccup from time to time, requiring a re-sync from PouchDB to LokiJS. This seems to be related to the app being restored or re-opened.
That's my experience so far. I wouldn't recommend it unless your app has few records and requires instant updates.
来源：https://stackoverflow.com/questions/45730820/sql-server-and-firebase-pouchdb-synchronization