從 WebSQL 到 IndexedDB 的轉換

Question

我目前正在開發一個用於提交考勤卡的移動應用程序，該應用程序可與現有的會計應用程序配合使用。 不用說，此應用程序嚴重依賴於關系數據庫，而這種特定的依賴轉化為移動應用程序。

在當前的 state 中，移動應用程序使用 WebSQL 離線訪問加載到設備上的表，同時用戶具有 inte.net 訪問權限。 時間卡在本地數據庫上創建，然后在用戶重新獲得 inte.net 訪問權限時上傳。 此功能是應用程序的核心。

我的問題是過渡到 IndexedDB 是否是 A.) 可行和 B.) 明智之舉。 如果 WebSQL 避免棄用，這就不是問題。 我開始更好地理解 IndexedDB 以及 JSON 如何使它對相對復雜的數據存儲有用，但我無法真正理解它是否真的可以復制關系數據庫的功能。

根據應用程序的要求，IndexedDB 似乎不是一個替代方案，但我對這個概念仍然很陌生並且願意接受啟發。

那么 IndexedDB 有可能成為替代品嗎？ IndexedDB 能否用於復制具有多個相關表和大量數據的數據庫的功能。 如果是這樣，我在哪里可以找到有關如何操作的信息。 如果沒有，我是否可以替代兩者？ （假設 WebSQL 實際上失去了支持並且 IndexedDB 不可行）。

在相關說明中，IndexedDB 會加速本地數據庫的填充嗎？ PHP 當前用於在用戶在線時填充數據庫，用大約一百個選項填充表確實需要相當長的時間。 當它接近一千時，應用程序就會完全崩潰（這種情況很少見，強烈建議客戶不要使用那么多數據）。

對此的任何幫助都會很棒，我對一般編程非常陌生，對 web 開發也非常陌生。

Answer 1

根據http://www.caniuse.com/indexeddb ，對 indexedDB 的支持相當有限，所以我暫時不會跳到它。 但是，當實施成熟時，這種情況很可能會在未來發生變化。

就個人而言，IndexedDB 看起來奇怪而復雜，尤其是當您 go 超越簡單的單表操作時。 我沒有對它運行任何實際測試，但由於您必須手動執行某些操作（如連接記錄），您最終會得到更多的 JS 代碼，這意味着更多的 bug 可以隱藏。

那么 IndexedDB 有可能成為替代品嗎？ IndexedDB 能否用於復制具有多個相關表和大量數據的數據庫的功能。 如果是這樣，我在哪里可以找到有關如何操作的信息。 如果沒有，我是否可以替代兩者？ （假設 WebSQL 實際上失去了支持並且 IndexedDB 不可行）。

快速搜索http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb ，其中顯示了 IndexedDB 多表使用的一些模式。 它還顯示了一些性能比較，這對於 IndexedDB 來說看起來很有希望。 但是，看到這個答案並對這個基准持保留態度。

在相關說明中，IndexedDB 會加速本地數據庫的填充嗎？ PHP 當前用於在用戶在線時填充數據庫，用大約一百個選項填充表確實需要相當長的時間。 當它接近一千時，應用程序就會完全崩潰（這種情況很少見，強烈建議客戶不要使用那么多數據）。

我是一個不同行業的類似應用程序的開發人員，我的經歷完全不同：即使在較舊的 iPhone 3GS 上，WebSQL 解決方案也能充分運行——我們已經測試了每個表有數千條記錄的模式，沒有明顯的減速。 您是否可以在單獨的事務中插入每一行？

我們的大多數客戶都對該應用程序感到滿意，因為它可以在 iPad、iPhone、Android 平板電腦和 Google Chrome 上運行。 但是一個客戶的安全要求只允許使用 Windows 和 IE，不允許使用其他瀏覽器或非 Windows 移動設備。 這是我們見過的唯一一種 WebSQL 無法解決的情況。 我們研究了 IndexedDB 和本機應用程序，到目前為止我們認為本機應用程序是一個更好的選擇（C# 基礎庫可以在 Xamarin 和 Windows 手機應用程序之間共享，更不用說 C# 比松散類型的 JS 回調更適合編寫代碼地獄）。

Answer 2

我遲到了幾年，但我想我會順便回答 OP 的問題（為了他的利益（可能）和任何發現自己有同樣問題的人的利益），這些問題還沒有直接回答，以及提供一些建議！

我有兩個替代方案嗎？ （假設 WebSQL 實際上失去了支持並且 IndexedDB 不可行）。

IndexedDB 是目前唯一保留在 W3C 標准軌道上的數據庫，因此，就本機客戶端數據庫 go 而言，它幾乎是唯一的選擇。

那么 IndexedDB 有可能成為替代品嗎？ IndexedDB 能否用於復制具有多個相關表和大量數據的數據庫的功能。

出色地...

IndexedDB 是一種非關系文檔存儲。

• 非關系：不允許定義存在於其 object 商店（表）中的條目之間的任何關系。 所有這些關系都必須由應用程序定義和維護。

• 文檔存儲：文檔的存儲庫，它們是任意結構化的數據項。

另一方面，關系數據庫支持表條目之間關系的定義和維護。 這些數據庫中的大多數也是行存儲，它們（您可能知道）是包含在表中的元組的存儲庫，這些表定義了它們各自的結構。

因此，要回答您的問題，是的，您可以在 IndexedDB 中復制關系數據庫提供給您的功能。 如果商店中的任何數據項以任何方式相互關聯，您將不得不在某種程度上關聯。

但是考慮到客戶端數據庫只是您數據的臨時中轉站，明智的做法是只復制最低限度的數據以保持那里數據的完整性，並且只需利用 rest 等功能一旦數據傳輸，它就存在於服務器端的關系數據庫中。

如果轉換的想法似乎仍然可以接受，go 就可以了！

但在您這樣做之前，您應該了解一些關於 IndexedDB 的事情。 考慮到它的數據庫類型，第一個應該是顯而易見的：它本身不支持 SQL。第二個是它的 API 是......至少可以說是笨拙的。

考慮到這些，我建議您查看BakedGoods 。 使用它，將一個或多個數據項放入 IndexedDB 數據庫中，例如，非常簡單：

bakedGoods.set({
    data: [{key: "key1", value: "value1"}, {key: "key2", value: "value2"}],
    storageTypes: ["indexedDB"],
    function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

由於某些關系數據庫功能的復制可能需要復雜的 CRUD 操作，您可能希望利用 BakedGood 對用戶定義的存儲操作功能的支持。

只是為了完全透明，BakedGoods 由這里的這個人維護:)。

Answer 3

通常使用 SQL 的開發人員由於其復雜的 api 而難以使用 indexeddb。

解決方案是使用任何使 indexedb 變得超級簡單的 indexedb 庫，但再次為了使用該庫，我需要了解 indexeddb 的一些概念。

JsStore是一個 indexeddb 庫，它消除了 indexeddb 的復雜性並使 indexeddb 的使用變得超級簡單。 提供Sql類api，簡單易學。

比方說 - 你有 sql 查詢： select * from table_name where id=1 and name='abc'

在 JsStore - 查詢將是：

var con = new JsStore.Instance(db_name);
con.select({
     From:table_name,
     Where: {
         Id: 1,
         Name:'abc'
     }
}).then(function(result){
   console.log(result)
})