请注意，当我说“客户”时，我指的是已注册该服务的企业或组织。
我正在创建一个错误跟踪应用程序。我决定采用多租户方法来处理应用程序实例和数据库。
因此，有一个巨大的错误表，其中包含来自所有客户的条目。错误ID是身份规范。因此，当任何客户端下的任何用户添加错误时，它会增加。对于仅添加了3个任务的客户，任务ID可以是＃45，＃49，＃53，因为来自其他客户的用户可能在其间添加了一些！
从用例的角度来看，这是否可以接受？
有时，客户可能会使用最新的错误ID来粗略衡量错误的数量。但实际上它将是系统中的TOTAL错误。或者如果他们的第一个错误从＃51134开始，他们会很惊讶！
另一方面，如果我在“幕后”拥有此特定ID，并分别为每个客户计算“可见”ID，他们将按顺序查看这些数字。但是，当将参考错误ID作为URL中的参数传递时，我无法使用用户可见ID，因为它不是唯一的。我不认为ClientID - BugID组合会很优雅。我担心使用原始身份规范值会导致混淆，因为用户将在UI中看到一个ID，并在URL中看到另一个ID。并且不必说开发人员会尝试通过更改ID来使用URL并观察它失败。
我该如何解决这个问题？我不想采用多数据库方法，因为我害怕维护和升级过程。
答案 0 :(得分：1)
我认为最少惊喜的原则适用于此：你需要与你做的任何事情保持一致。如果您无法修改URL方案，那么只需将非顺序ID作为唯一可行的解决方案。我个人没有看到这个问题，大多数错误跟踪器都能够生成报告，说明在给定时间段内报告了多少错误，或者在特定项目中报告了多少错误等。
稍微不相关的说明，在工作中我们为所有项目使用单一的错误跟踪系统。整个系统对于任何项目中的错误都有一个递增ID。我们从来没有遇到过这样的问题。
答案 1 :(得分：0)
根据一般的经验法则，如果您可以提供帮助，请不要向您的用户显示您的代理键（IDENTITY值）。人类最终想要改变他们所知道的东西，这样他们就不需要知道主键价值了......
关于生成人工耗材标识符的想法可以最好地解决您的问题，正如您所提到的，只是不要像系统中的密钥那样使用它。使用您的代理键作为键。 （通常有一些方法可以在url字符串中传递密钥...）而是将人类可消耗密钥作为初始生成后的显示字段处理。
考虑连接客户名称缩写或客户公司缩写或日期/时间的一部分或您使用针对上下文（SELECT MAX(?) FROM q）的单独查询或其组合确定的其他计数器......
答案 2 :(得分：0)
我想提一个特例：如果这是一个面向公众的网站，即公共支持页面或类似网站，客户通过电话向您提供支持票号（即断开通信媒介）那么这将是明智的构建一个“智能”的id。例如5个数字+校验和。然后，操作员（或系统）可以更轻松地检查误读票号。