問題

我一直傾向於在資料庫中使用長整數作為主鍵,以簡單和(假設)速度.但是當使用 REST 或物件例項的Rails-like URL方案時,我會最終得到這樣的URL:

 http://example.com/user/783
 

然後假設也有使用者的ID為782,781,...,2和1.假設有關的Web應用程式足夠安全,可以阻止人們未經授權進入其他數字以檢視其他使用者,一個簡單的後置分配的代理鍵也“洩漏”例項總數(比這個更大),在這種情況下,使用者可能是特權資訊. (例如,我是stackoverflow中的使用者#726.)

UUID / GUID是一個更好的解決方案嗎?然後我可以設定這樣的URL:

 http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66
 

不完全簡潔,但是關於顯示使用者的隱含資訊較少.當然,它暗示了“透過隱蔽性的安全性”,這不能替代正確的安全性,但似乎至少有點安全.

這個好處值得為web-addresserve物件例項實現UUID的成本和複雜性嗎?我認為我仍然想要將整數列作為資料庫PK來加速連線.

還有UUID的in-database表示的問題.我知道MySQL將它們儲存為36-字串. Postgres似乎有更高效的內部表示(128位?)但我自己沒有嘗試過.有人有這方面的經驗嗎?


更新:對於那些只在URL中使用使用者名稱的人(例如, http://example.com/user/yukondude ),對於具有唯一名稱的物件例項工作正常,但是對於真正只能透過數字識別的zillome的Web應用程式物件怎麼樣?訂單,事務,發票,重複影象名稱,stackoverflow問題,...

  最佳答案

我不能說你的問題的Web端.但uuids對ntier應用程式很好. PK生成可以分散:每個客戶端生成自己的pk而不會碰撞. 速度差一般很小。

確保資料庫支援有效的儲存資料型別(16位元組,128位)。 至少可以在 base64 中編碼 uuid 字串並使用 char(22)。

我已經廣泛使用了Firebird,並且做推薦。

  相同標籤的其他問題

databaseweb-applicationsuuid