爲IndexedDB鍵生成UUID？

Question

爲索引資料的W3C規範定義a key generator爲：

甲密鑰發生器產生每個需要密鑰時間單調增加的號碼[原文如此]。現在

，看來（我），對IndexedDB的一個常見用例（或者，就此而言，任何HTML5客戶端存儲選項：的WebSQL，localStorage的等等），將應用程序設計工作離線（結合HTML5 ApplicationCache）。

在這種情況下，已斷開連接的 Web應用程序可能會在其本地數據存儲區中生成新的對象/記錄，稍後在與服務器的連接可用時同步到集中式數據庫。此外，多個客戶端同步到相同集中式數據庫的任何應用程序通常需要防止ID衝突的機制。

UUID（或GUID）是一個不錯的選擇，因爲它可以在沒有任何中央協調的情況下生成唯一的密鑰生成。相比之下，「單調增加數字」是一個糟糕的解決方案（除非每個客戶端的「起始值」與其他用戶不太可能發生衝突）。

我感到奇怪的是，IndexedDB規範沒有指定（或者甚至允許將來的支持）備用密鑰生成器，比如UUID生成器。有些人可能會建議答案完全不是使用IndexedDB的內置密鑰生成器，而是讓應用程序生成它自己的密鑰。但是，雖然有很多基於Javascript的UUID生成器可用，但它們中的很多似乎基於Math.random（），它具有隨機性的已知限制，因此可能不是一個好選擇如果絕對唯一的密鑰必須得到保證。

由IndexedDB實現者提供的本地UUID生成器（可能）會比應用程序實現/導入的腳本更健壯並且性能更好;人們會想。

所以我錯過了這裏的一些東西，還是W3C IndexedDB工作組錯過了一個機會？

Answer 1

這是一個很費力的問題，但是如果你想在使用IndexedDB幾年後想到它，我會說UUID API會很好，但它似乎超出了工作組的範圍試圖實現。

UUID是「普遍」唯一的UUID。 IndexedDB中唯一性的最高概念是對象存儲，數據級別和瀏覽器級別的數據庫。

實際上，我喜歡在新的數據庫或對象存儲區上重新運行代碼時，我可以獲得可預測，可重複的結果。雖然我可以看到所有客戶端數據庫都需要保持唯一性的情況，但我絕對不希望它成爲默認值。

我個人並不要求我的客戶端數據庫具有通用的唯一性，但是，無論如何，如果您有這樣的UUID JS實現，那麼可以使用。

Answer 2

objectStore鍵對於本地數據庫中的objectStore是唯一的，除此之外沒有別的。任何關於唯一性的更高層次的語義都超出了IndexedDB的範圍。你描述UUID，但即使這只是一種獨特的密鑰形式。有很多不同的方法來生成具有不同屬性的UUID，包括特定的前綴與單調增加的低位組合，隨機生成整個事物，通過以太網卡地址對其進行作用域等。

通過選擇一些僅限於本地實例，IDB（無論好壞）都會迫使開發人員對「全局」唯一密鑰進行慎重選擇。