SQL Server和Firebase/PouchDB同步

Question

我正在構建一個Web應用程序，客戶端需要在離線時瀏覽器訪問數據存儲。我正在考慮在應用程序內部使用Firebase或PouchDB數據庫來實現此目的。

但是，對於後端，我使用的是SQL Server。我可以將來自Firebase/PouchDB的數據同步到ms sql server引擎並持久存儲嗎？ MS SQL Server的JSON支持是否允許我這樣做，或者我是否浪費時間沿着這條路線走？ 該應用程序正在使用Node.JS

任何幫助/建議將是偉大的。

Answer 1

PouchDB是離線支持的絕佳選擇！不過，您應該提供一個與服務器端相同的東西，因此PouchDB可以發揮其實力：複製。使用CouchDB（穩定且經過驗證，經過戰鬥測試的「原創」），IBM Cloudant（兼容數據庫即服務）或PouchDB服務器（該塊中的新成員，JavaScript中的CouchDB實現仍然年輕）。

您可能然後嘗試從CouchDB獲取數據到SQL Server中，但您的真相源應始終爲CouchDB，因爲兩個數據庫之間存在太多體系結構差異。寫文檔到CouchDB就像是一個API調用，所以我建議給CouchDB一個嘗試！

Answer 2

PouchDb服務器有support for LevelUp，它允許您將後端服務器換出別的東西。某些SQL數據庫受支持（例如MySQL和Postgres），但我不認爲SQL Server就是其中之一。

如果您準備考慮替代SQL解決方案，則應該可以擁有本地PouchDb數據庫並通過PouchDb服務器將其與SQL數據庫一起復制。我雖然沒有嘗試過！

Answer 3

使用MSSQL < - > CouchDB < - > PouchDB方法有一些嚴重的優點和缺點。我剛剛完成了將部分應用程序遷移到此方法的過程，並將概述我發現的內容。

我們正在跨80個表（舊方法）同步大約400K條記錄，並且跨3個表（大約新方法）約6000行。

老方法：MSSQL < - > REST API < - > SQLite的（移動）

• 定製API使用PHP編寫的 '最後誰拯救' 處理
• 偶爾同步衝突。
• 約20K-40K行速度保存到手機上。
• 由於我在移動端的自定義寫入同步部分導致的各種故障。 （寫穩定的同步軟件有很多隱性的挑戰）

的新方法：MSSQL < - > CouchDB的< - > PouchDB < - > LokiJS

• 測試數據的小部分（6000行），只有一部分的應用程序。
• PouchDB正在使用IndexedDB適配器。（接下來測試SQLite本地適配器）
• MSSQL - > CouchDB每隔20秒左右發生一次（查詢）。
• CouchDB - > MSSQL隨時會發生CouchDB（更改提要）的更改。
• CouchDB < - > PouchDB非常穩定！和慢（約300行/秒）！
• 與原生SQLite相比，PouchDB本身在查詢索引時速度非常慢。對於查詢5000條左右的記錄，我們談論的時間約爲10秒，而在SQLite中則爲幾毫秒。
• 我只使用LokiJS查詢部分。速度幾乎與SQLite相匹配。這意味着通過PouchDB更改提要保持LokiJS最新，當應用程序從鎖定的手機恢復或從後臺進程恢復時，似乎偶爾會失敗。
• 當PouchDB恢復同步（比如剛剛打開應用程序或從後臺重新打開應用程序）時，需要一段時間才能跟上。在一個美好的日子裏，它似乎每秒同步約300行左右。有時候，這種同步會在應用程序啓動後的5到15秒內啓動，這意味着用戶可能不會查看最新的數據。一旦同步正在運行，取決於它離線的時間長短，用戶可能會在PouchDB追上時「停留」一分鐘左右。
• PouchDB一旦被抓住，變化飼料就像魔術一樣，任何對我們的移動設備所做的任何更改都會立即推送到CouchDB，然後推送到所有其他設備（以及我們的服務器）。我編寫了UI，以便根據更改進行更新，從而爲每個人提供最新信息。這部分工作得很好。 CouchDB的& PouchDB的

優勢在我的設置

• CouchDB的& PouchDB同步的穩定性。
• 將記錄存儲爲JSON使它們在JavaScript中使用起來容易得多。 CouchDB的&的

缺點PouchDB

• 的同步超過幾個記錄更多的是緩慢的速度。
• PouchDB查詢的速度很慢（與原生SQLite相比）。
• PouchDB更改提要似乎不時打嗝，需要從PouchDB重新同步到LokiJS。這似乎與應用程序正在恢復或重新打開有關。

這是我迄今的經驗。我不會推薦它，除非你的應用程序有很少的記錄，並需要即時更新。