CouchDB - 人類可讀的編號

Question

我使用CouchDB和node.js.現在有一個節點參與其中，即使在遙遠的未來也不打算改變它。雖然我可以刪除大多數情況下需要一個簡短的和自動增量的（它可以是稀疏的，但不是隨機的）ID，但仍然有一個地方用戶實際需要輸入產品的ID。我希望保持這個ID儘可能短，並且以比'4ab234acde242349b'更類似於人的可讀格式，因爲它有時必須手工輸入等等。

然而，在數據庫中，它可以存儲任何ID請求CouchDB（使用默認的自動生成的UUID），但應該可以給它一個數字，它也可以用來標識它。我想過的是創建一個由CouchDB中的所有UUID組成的數組。當我在節點中創建一個新產品時，我會運行一個更新處理程序，它在最後使用新的唯一ID更新所述文檔。要獲得產品ID，我會查詢數組和客戶端使用indexOf我可以得到索引作爲一個簡短的ID。

我不知道這是否可行。從性能角度來看，我可以這樣說：還有更多的查詢應該使用數字ID - > uuid而不是uuid - >數字ID。數據庫中每年最多會有7000個新條目。另外，沒有用例可以刪除產品，但我不想依賴這個。

是否有其他適用的方法可以生成可與我的文檔關聯的更短且更人性化的ID？

/編輯 從技術角度來看：它似乎在工作。我可以做兩個轉換號碼< - > uuid，它似乎進展順利。我現在不用，如果這適用於複製和東西，但因爲有數組我認爲它應該，對吧？

Answer 1

你有兩個選擇：

1. 設置你的人類可讀的ID作爲_id場。基本上你可以設置創建文件調用數據庫，它會接受它。這可能是一個更輕量級的解決方案，但它帶有一些限制：

   1. 它必須是唯一的。您應該小心嘗試創建文檔的客戶端，而是覆蓋現有的文檔。
   2. 它只能包含字母數字或一些特殊字符。根據我的經驗，要求有額外字符類型的麻煩。
   3. 它不能超過理論字符串長度限制（Couchdb沒有定義任何，但你應該）。 Long ids will increase your views(indexes) size really bad。 And it might make it s lower。

   如果這些東西對您沒有問題，那麼您應該使用此解決方案。

2. 正如你所說，讓_id是一個UUID，並將人類可讀的ID設置爲另一個字段。要通過人類可讀的ID訪問文檔，只需創建一個view發送人類可讀的ID作爲密鑰，然後將該文檔作爲值發送或通過include_docs=true選項獲取文檔。每當到達視圖時，Couchdb將逐步更新視圖並返回列表。這與創建一個帶有ID的數組/對象的文檔完全相同。除了使用couchdb視圖外，您可以獲得更多性能。

   這在查詢和插入時可能會稍微慢一些。如果順序插入了ID，則沒問題，CouchDB will slightly take more time to insert it at the right place。這些對於在數據庫中插入的大量插入不起作用。

   查詢不應超過總查詢時間超過第一個選項的10％。我認爲10％確實是一個很大的數字。這個數字很可能不到5％，我記得在我的CouchDB應用程序中，我從一個關鍵字的視圖切換到從一個視圖讀取，而從用戶端點緩慢下來的時候，同時，它並不明顯。

   這是怎樣的人，比其他ID查詢領域的文件，如查詢與電子郵件，當用戶在登錄用戶的文檔。

如果你不知道怎麼意見工作的CouchDB ，您應該閱讀couchdb definite guide book的views chapter。

另外，請確保您遠離文件內巨大的數組。我認爲CouchDB每個文檔的限制爲4GB。我記得有很多文件，並且它有很長的查詢時間，因爲視圖必須迭代每個數組項目。最後爲每個數組項目，而是我創建了一個文檔。它快得多。