我当前的架构如下所示：
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列VARCHAR(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保留为legacy Account Number并为所有新记录创建新的标识值。这将要求最终用户熟悉新的Account Number。这可能是最简单的，但不确定是否有任何缺点。
如果还有其他情况，您知道在这种情况下效果会很好，请告诉我。
答案 0 :(得分：0)
您不应将帐户ID等业务密钥用作身份。创建一个新的id列，并使用autoincrement字段或guid填充它。与您的系统交互的用户或其他系统不应该知道/依赖于此值。