我当前的架构如下所示：
ID | DisplayVal
-- ----------
1 1-H-3
2 2-H-3
3 3-J-4
在上面，该ID字段是一个IDENTITY INT也用作最终用户的字段account Id。这DisplayVal就是他们在屏幕上看到的。
一个新客户提供了他们自己的Account Id价值观，但他们是alpha-numeric，所以他们不能只是进入该IDENTITY领域。以下是我的场景： 我正在寻找能够提供最佳maintainability、end user experience和magnitude and impact of changes的场景testing/QA impact。
我的第一个场景是添加一个Account Number列，该列将是 aVARCHAR(x)并容纳所有类型的Account Numbers. 它看起来像这样：
ID | DisplayVal | AccountNumber
-- ---------- -------------
1 1-H-3 1
2 2-H-3 2
3 3-J-4 3
4 h389 h389
5 h-400-x h400
在上面，在第一个客户端的情况下，seeded Identity将Account Id被复制到 中Account Number，但对于另一个客户端，仍然会seeded Identity创建一个，但它们Account Number会有所不同，它可能与 . 匹配，也可能不匹配Display Value。
我的第二种情况是不添加任何列，对于提供 的客户端Account Number，我将关闭IDENTITY INSERT并插入新的 Id，然后重新打开身份插入。如果客户没有提供Account Number，我会自动生成一个，显然是为了避免冲突。
第三种情况基本上是将新Account Number的作为 alegacy Account Number并为所有新记录创建新的身份值。这将要求最终用户熟悉新的Account Number. 这可能是最简单的，但不确定是否有任何缺点。
如果您知道在这种情况下会很好地工作的另一种情况，请告诉我。