隨機ID生成器，映射與同列

有幾個實體我們希望隱藏客戶的確切ID - 主要原因是我們不希望客戶知道它們中有多少個DB。隨機ID生成器，映射與同列

例如從URL，http://mydomain/user/get/27，它說這是第27個用戶。

因此，我正在實施一種分配隨機ID（必須是唯一的）的解決方案。換句話說，我們不是使用唯一的序列號，而是尋求獨特的非序列+隨機數解決方案。

例如從URL，http://mydomain/user/get/8534023，這實際上是第27個用戶。

我的問題在於，知道這裏的某些用戶可能對類似問題有經驗，我應該使用映射還是將隨機ID分配給主鍵列？

例如

CREATE TABLE IF NOT EXISTS `test` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `somethingElse` varchar(255) NOT NULL, 
    PRIMARY KEY (`id`) 
) 

CREATE TABLE IF NOT EXISTS `map` (
    `id` int(10) unsigned NOT NULL, 
    /* Foreign Key to test table */ 
    `parent` int(11) NOT NULL, 
    PRIMARY KEY (`id`), 
    KEY `parent` (`parent`) 
)

VS.

CREATE TABLE IF NOT EXISTS `test` (
    /* Assign random ID here */ 
    `id` int(10) unsigned NOT NULL, 
    `somethingElse` varchar(255) NOT NULL 
    PRIMARY KEY (`id`) 
)

對我來說，後者來更加得心應手，因爲我沒有保持一個地圖，我也可以選擇自定義的DAO /應用程序使用映射的ID（或確切的ID內部）。對於這兩種情況，我都必須編寫自己的隨機ID生成器。

來源

2010-01-24 yclian

你是對的 - 後者是更好的方法。這是一對一的關係 - 沒有理由有一個單獨的表。我建議有：

上的「假貨」 user_ID的指數，因爲它會被用於查找
在列的唯一約束，以確保重複的值不會插入

您的關注也是有效的，不會暴露實際的主鍵值。它確保瞭如果數據庫發生變化，並且實際的主鍵值發生了變化 - 用戶將不知道更改。

來源

2010-01-24 04:03:54

+1這絕對是擁有「功能」鍵的最佳做法。 – 2010-01-24 04:47:20

爲什麼不直接將增量種子開始值設置爲8534023之類？你的第一個客戶是8534023，你的第二個客戶是8534024等。你的客戶永遠不會知道這意味着什麼，但你會。

來源

2010-01-24 03:57:38

+1不錯的解決方案！ – jspcal 2010-01-24 04:00:00

數據庫之間的遷移可能會導致不同的關鍵值 - 使用代理鍵會使用戶不知道發生了變化。 – 2010-01-24 04:05:42

但仍然順序;所以你仍然在泄漏年表信息。 – lhunath 2010-01-27 09:09:18

隨機ID生成器，映射與同列

回答

相關問題