我们目前有一个用户登录的网站。
我们有一个带有 userId 的用户表。
我们现在希望用户有一个重复的个人资料，这与他们的主要个人资料完全分开。这需要是一个秘密档案。
现在我们可以只将两条记录添加到数据库中，但 id 将是连续的（直到我们达到很高的注册命中率），因此用户可以锻炼 userId 将与更高的一个 ID 相关联。
我意识到这不是一个理想的解决方案，但它是一个大型软件项目的后期更改，因此我们试图尽可能务实，同时尽可能少地更改代码。
选项：
- 关闭自动增量 ID，并构建我们自己的 keyGeneration 表。从 0 开始一张表，在 1000000000 开始一张秘密表。然后我们可以关闭用户表中的自动递增 ID，并使用这些密钥。
问题是，运行键 1,1000000000,2,1000000001,3,1000000002 是否会导致大量索引问题？我们是否必须一直强制重建索引？
- 我们只为第二个配置文件 id 键入一个单独的表，再次从 10000000000 开始。然后我们修改所有代码以检查 id > 999999999 并翻转服务器端的逻辑，以便查找正常工作。
意味着在从前端将用户 ID 传递到站点的任何地方进行检查。
由于我们没有做太多，（我们显然主要是安全地获取登录用户的 userId，它可能没那么糟糕。
无论如何，只是想知道是否有人对此有任何想法？
///////编辑
为了进一步说明这一点，想象在 stackoverflow 或 facebook 上，您有 2 个可以控制的配置文件，它们之间没有链接。就像 Facebook 上的多个用户都可以充当主页帐户一样，但没有从该帐户返回到真实用户个人资料的链接。
本质上是为了不破坏参照完整性或重新编写太多代码，我真的想将一个 ID (int) 传递回这些帐户的前端。然后整个系统就像它所做的那样继续滴答作响。
指南可能很酷！但这会产生性能开销（不是我真正关心的；），但这也意味着编写大量代码来处理传递给前端的 Guids（不是我们依赖前端变量是正确的）但这就是为什么我建议上面的高 int 解决方案。由于我们仍然在后台潜伏着 ASP.NET 成员资格，我几乎认为这可能会很好，但是 A）我们计划有一天删除那个（或迁移到简单的成员资格）b）我们在用户表中使用顺序 Guid 生成来提高性能（在需要之前再次抱歉谈论优化）