나의 현재 스키마는 다음과 같습니다 : 위의에서어떤 스키마 변경 시나리오입니까?
ID | DisplayVal
-- ----------
1 1-H-3
2 2-H-3
3 3-J-4
을의 ID 필드도 같이 최종 사용자 account Id 사용되는 IDENTITY INT 필드입니다. DisplayVal이 화면에 표시됩니다.
새 클라이언트가 Account Id 값을 제공했지만 alpha-numeric이므로 IDENTITY 필드로 갈 수 없습니다. 내 시나리오는 다음과 같습니다. 가장 좋은 시나리오를 찾고 있습니다. maintainability, end user experience, magnitude and impact of changes 및 testing/QA impact.
첫 번째 시나리오는 VARCHAR(x)이 될 Account Number 열을 추가하고 모든 유형의 Account Numbers을 수용하는 것이 었습니다. 첫 번째 클라이언트의 경우, 위의에서 Account Id이 Account Number에 복사 할 것입니다 seeded Identity을
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 Number은 다를 수 있으며 Display Value과 일치하거나 일치하지 않을 수 있습니다.
두 번째 시나리오는 열을 추가하지 않고 Account Number을 제공하는 클라이언트의 경우 IDENTITY INSERT을 해제하고 새 ID를 삽입 한 다음 ID 삽입을 다시 켭니다. 클라이언트가 Account Number을 제공하지 않으면 자동으로 충돌을 피하려고하는 것으로 자동 생성합니다.
세 번째 시나리오는 기본적으로 새로운 Account Number을 legacy Account Number으로두고 모든 새 레코드에 대해 새 ID 값을 만드는 것입니다. 따라서 최종 사용자는 새로운 Account Number에 익숙해 져야합니다. 아마도 가장 쉬운 방법 일 수는 있지만 단점이 있는지 확실하지 않습니다.
이 경우 제대로 작동하는 시나리오가 있다면 알려주십시오.