我和我的同事正在讨论使用哪种方法来自动生成用户 ID 和帖子 ID 以在数据库中进行识别：
一个选项使用 Random 的单个实例，并采用一些有用的参数，以便它可以重用于各种字符串生成情况（即从 4 位数字 pin 到 20 位字母数字 id）。这是代码：
// This is created once for the lifetime of the server instance
class RandomStringGenerator
{
public const string ALPHANUMERIC_CAPS = "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
public const string ALPHA_CAPS = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
public const string NUMERIC = "1234567890";
Random rand = new Random();
public string GetRandomString(int length, params char[] chars)
{
string s = "";
for (int i = 0; i < length; i++)
s += chars[rand.Next() % chars.Length];
return s;
}
}
另一个选项就是使用：
Guid.NewGuid();
see MSDN 上的 Guid.NewGuid http://msdn.microsoft.com/en-us/library/system.guid.newguid.aspx
我们都知道Guid.NewGuid()可以满足我们的需求，但我宁愿使用自定义方法。它做同样的事情，但有更多的控制。
我的同事认为，由于自定义方法是我们自己编写的，因此更容易产生冲突。我承认我并不完全了解 Random 的实现，但我认为它与 Guid.NewGuid() 一样随机。自定义方法的典型用法可能是：
RandomStringGenerator stringGen = new RandomStringGenerator();
string id = stringGen.GetRandomString(20, RandomStringGenerator.ALPHANUMERIC_CAPS.ToCharArray());
Edit 1:
- 我们使用的 Azure 表不具有用于生成密钥的自动增量（或类似）功能。
- 这里的一些答案只是告诉我使用 NewGuid() “因为这就是它的用途”。我正在寻找更深入的原因，以解释为什么在与 Guid 具有相同自由度的情况下，熟化方法可能更有可能产生碰撞。
Edit 2:
我们还使用了 Cooked up 方法来生成帖子 ID，与会话令牌不同，它需要看起来漂亮才能在我们网站的 URL 中显示（例如http://mywebsite.com/14983336 http://mywebsite.com/14983336），所以这里不可以选择引导，但是仍然要避免冲突。
