2

请注意，当我说“客户”时，我指的是已注册该服务的企业或组织。

我正在创建一个错误跟踪应用程序。我决定对应用程序实例和数据库都采用多租户方法。

因此，有一个巨大的错误表，其中包含来自所有客户端的条目。错误 ID 是一种身份规范。因此，当任何客户端下的任何用户添加错误时，它都会增加。对于只添加了 3 个任务的客户端，任务 ID 可能是 #45、#49、#53，因为其他客户端的用户可能在两者之间添加了一些！

从用例的角度来看，这是否可以接受？

有时，客户可能会将最新的错误 ID 作为错误数量的粗略衡量标准。但实际上这将是系统中的全部错误。或者，如果他们的第一个错误是从 #51134 开始的，他们会感到非常惊讶！

另一方面，如果我在“幕后”有这个特定的 ID，并分别为每个客户计算一个“可见的”ID，他们将按顺序看到这些数字。但是，当在 URL 中将参考错误 ID 作为参数传递时，我不能使用用户可见的 ID，因为它不是唯一的。我不认为 ClientID - BugID 组合会很优雅。恐怕使用原始标识规范值会引起混淆，因为用户会在 UI 中看到一个 ID，而在 URL 中看到另一个 ID。无需说开发人员会尝试通过更改 ID 来使用 URL 并观察它失败。

我该如何解决这个问题？我不想采用多数据库方法，因为我有点害怕维护和升级过程。

4

3 回答 3

1

我认为最小意外原则适用于此：无论做什么，你都需要保持一致。如果您无法修改 URL 方案，那么只会将非顺序 ID 作为唯一可行的解​​决方案。我个人认为这没有问题，大多数错误跟踪器将能够生成报告，说明在给定时期内报告了多少错误，或者在特定项目中有多少错误等。

稍微无关紧要的是，在工作中，我们对所有项目都使用一个错误跟踪系统。整个系统对于任何项目中的错误都有一个递增的 ID。我们从来没有遇到过问题。

于 2011-05-14T13:43:52.813 回答
0

作为一般经验法则，如果您可以提供帮助，请不要向您的用户显示您的代理键（IDENTITY 值）。人类最终想要改变他们知道的东西，所以他们不需要知道主键值......

正如您所提到的，关于生成人类可消费标识符的想法将最好地解决您的问题，只是不要将它用作系统中的密钥。使用您的代理键作为键。（通常有一些方法可以在 url 字符串中传递键...）相反，将您的人类消耗键视为初始生成后的显示字段。

考虑将客户名称缩写或客户公司缩写或日期/时间的一部分或您确定的其他计数器与针对上下文 ( SELECT MAX(?) FROM q) 的单独查询或这些组合...

祝你好运！

于 2011-05-14T13:49:13.950 回答
0

One special case I wanted to mention: if this is a public facing website, i.e. public support page or similar, where the customer gives you the support ticket number by phone (i.e. break of the communication medium) then it would be wise to construct an "intelligent" id. For example 5 numbers + checksum. Then the operator (or the system) can more easily check for misread ticket numbers.

于 2011-05-14T14:03:06.947 回答