0

私の現在のスキーマは次のようになります。

ID | DisplayVal
--   ----------
 1     1-H-3
 2     2-H-3
 3     3-J-4

上記のIDfield は、IDENTITY INTend user としても使用されるフィールド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ます。

私の 2 番目のシナリオは、列を追加せずAccount Number、IDENTITY INSERT. クライアントがAccount Number.

3 番目のシナリオは、基本的に、新しいものを のままにしてAccount Number、legacy Account Numberすべての新しいレコードに対して新しい ID 値を作成することでした。これには、エンド ユーザーが新しい に慣れる必要がありますAccount Number。おそらく最も簡単ですが、欠点があるかどうかはわかりません。

この場合にうまく機能する別のシナリオがわかっている場合は、お知らせください。

4

1 に答える 1

0

アカウント ID などのビジネス キーを ID として使用しないでください。新しい id 列を作成し、自動インクリメント フィールドまたは GUID を使用して入力します。システムと対話するユーザーまたは他のシステムは、この値を認識したり依存したりしてはなりません。

于 2012-10-12T19:06:25.950 に答える