生成主鍵：通過從存儲的Ids中提取，保存在Web應用程序的應用程序層

我正在構建一個使用分佈式NoSQL DB的Web應用程序。但是，爲了爲新實體生成Ids，我使用MySQL作爲Flickr's ticket server 生成主鍵：通過從存儲的Ids中提取，保存在Web應用程序的應用程序層

我只是堅持讓Ids的庫存保持在應用程序層的想法，以便更新的實體可以很容易地以快速方式分配ID ，而不需要從數據庫中逐一提取每個數據庫。相反，我可以從數據庫中提取大約1000個Ids，並使用它們，直到堆棧達到剩餘Ids的一定限制時，我會從DB中抽取更多Ids以再次填充堆棧。

您的想法和想法，讚賞。

來源

2011-03-12 Rajat Gupta

這是一個好主意，除非你需要你的ID是連續的，並且可以確保某些ID不會被使用。

例如當SAP ERP沒有訂購要求並且可能存在「漏洞」時，SAP ERP就可以完成它所謂的「數字範圍」。每個應用程序服務器都會請求一組密鑰而不是一個密鑰，並將其從這個緩存中提供出來。它會在需要時重新填充緩存。這樣可以節省很多往返時間並鎖定數據庫。

如果應用程序服務器出現故障（或系統已停止），則存在於緩存但尚未分發的任何ID都會丟失（即永遠不會使用）。如果你所需要的只是一個唯一的ID，這有時會很好。如果序列中沒有漏洞（對於某些國家/地區的商業憑證編號（例如發票號碼）），則根本沒有問題。

來源

2011-03-12 09:28:37 Mat

謝謝。你完全理解我的觀點..！另外爲什麼即使有需要的堆棧，它也可能只是一個靜態計數器，因爲Ids的庫存是連續的。 – 2011-03-12 09:37:48

那麼這個ID必須是全球唯一的。所以你需要確保你使用的任何實現至少是線程安全的，並且全局一致。「靜態計數器」聽起來不太好，因爲它們通常不是線程安全的（取決於語言，上下文，原子性保證或缺失等）。但是有很多實現它的方法，不需要複雜的隊列或堆棧類型結構。（你可能不在線程環境中。） – Mat 2011-03-12 09:43:17

儘管這可行，但您可能會增加不必要的複雜性。

通用唯一ID專門用於這種情況。 A previous answer here on SO contains a pure-PHP UUIDv4 generator，如果你不喜歡使用the UUID PECL extension。

的UUID的主要缺點是，他們醜陋，雖然他們可以在其他形式的僅僅是異想天開長表示。

來源

2011-03-12 19:46:46 Charles

好的建議，但我試圖避免UUID的原因是因爲我的數據庫嚴重非規範化和更多我想緩存包含這些Ids作爲列的我的數據庫行，我會喜歡比128位更小的東西，也許是i32 ID。 – 2011-03-13 07:13:33

生成主鍵：通過從存儲的Ids中提取，保存在Web應用程序的應用程序層

回答

相關問題