자동 증가 기능이있는 사용자 정의 PrimaryKey 생성

둘 이상의 테이블에 대한 기본 키를 정의하고 생성해야합니다. 두 CUSTOMER_ID C_NAME, CITY, 같은 동일한 열을 유지 LOCAL_CUSTOMERS
TableB의 = INTERNATIONAL_CUSTOMERS자동 증가 기능이있는 사용자 정의 PrimaryKey 생성

테이블 데이터의 동일한 유형을 유지하지만 일부 비즈니스 규칙에 대한 우리는 그들이

TableA의 같은 말을 분리해야한다. ... etc

기본 키를 디자인하는 동안PREFIX와 자동 생성 된 숫자의 조합으로이 키를 자동으로 증가 시키므로 int PK가 수행합니다.

예

, CUSTOMER_ID 테이블에 대한 (PK) "LOCAL_CUSTOMERS"

LOC1, LOC2, LOC3 ...... LOC5000

및 테이블 CUSTOMER_ID (PK) "INTERNATIONAL_CUSTOMERS"

INT1, INT2, INT3, ...... INT5000

여기서 LOC 및 INT는 LOCAL, INTERNATIONAL의 접두어입니다.

int를 사용하여 "신원 확인"에서 자동 증가를 설정할 수 있지만 어떻게 할 수 있습니까? 열을 설정해야하는 "Computed Column Specification"입니까?

감사합니다.

출처

2010-01-03 Asad Butt

계산 된 열을 사용하여이 작업을 수행 할 수 있습니다.

당신이 두 개의 테이블을 고수하는 경우 어느 쪽이, 당신은 단지 이런, 지속 열 하나의 계산을 추가 할 수

ALTER TABLE Local_Customer 
    ADD CustomerID AS 'LOC' + CAST(ID AS VARCHAR(7)) PERSISTED 

ALTER TABLE International_Customer 
    ADD CustomerID AS 'INT' + CAST(ID AS VARCHAR(7)) PERSISTED

당신이 discrimator 열, 예를 들어, 단일 테이블을하기로 결정하는 경우 "IsDomestic"형 BIT, 당신은 "IsDomestic"컬럼의 값에 따라 접두어로 "LOC"또는 "INT"를 사용하는 하나의 계산 열 할 수있는 :

ALTER TABLE Customer 
    ADD CustomerID AS CASE IsDomestic WHEN 0 THEN 'INT' ELSE 'LOC' END + CAST(ID AS VARCHAR(7)) PERSISTED

어느 방법을 - 당신의 " ID 유형 "INT IDENTITY"필드는 각 행에 대해 자동으로 증가되며 계산 된 열은 사용자가 더 이상 노력하지 않아도 사람이 읽을 수있는 "CustomerID"를 자동으로 만듭니다.

출처

2010-01-04 06:19:46

문제를 이해하고 "솔루션"을 제공해 주신 데 대해 감사드립니다. –

영역 ID 및 자동 ID보다 복합 키를 사용할 수 있습니다.

에는 삽입시 pk를 사용자 정의 문자열로 설정할 수있는 트리거가있을 수도 있습니다.

일반적으로이 테이블은 동일한 테이블에 유지되고 로컬 대 intl 만 다른 경우에만 유지하는 것이 가장 좋습니다.

출처

2010-01-04 00:05:53 jspcal

가능한 한 동일한 테이블에 보관하고 현지 고객과 해외 고객을 구별하기 위해 다른 열을 추가해야한다고 생각합니다. 2 개의 테이블을 사용하면 앞으로이 테이블에서해야 할 모든 작업을 두 배로 늘릴 수 있습니다. 계산 된 varchar 대신 id 값을 사용하는 것은 말할 것도없이 long id를 단순하게 생성했습니다.

출처

2010-01-04 00:09:12

구현하려고하는 것은 동일한 유형의 객체의 특수한 경우 인 부속 유형이라고합니다. 이를 구현하는 몇 가지 일반적인 방법이 있습니다.

두 유형 모두에 필요한 모든 열을 포함하는 하나의 표를 만듭니다. 모든 유형에 적용되지 않는 속성에는 NULLable 열을 사용하고 다른 모든 속성에는 필수 열을 사용합니다. 테이블이 하나뿐이므로 pk에서만 가능합니다.
모든 공통 등록 정보 (기본 유형)에 대해 생성 된 pk로 하나의 테이블을 작성하십시오. 각 하위 유형에 대해 별도의 표를 추가하십시오. 이 테이블에는 외래 키를 사용하여 기본 유형의 pk를 가리키는 pk가 있습니다 (따라서 기본 유형과 1 : 1 관계를 가짐).그래서 두 가지 유형이 키 값

의 동일한 세트에서 그릴 (가 더 많은 방법이 있지만이 가장 유용하고 가장 인기있는) 내가 "스마트"키의 모든 종류에 대해 vehementlyu 권합니다

. 물론, 테이블에있는 "유형"열 (기본 유형의 열)을 사용하여 처리 대상을 신속하게 결정할 수 있습니다. 그러나 당신과 같은 핵심 계획은 실제 가치가없는 것들을 복잡하게 만드는 것일뿐입니다.

출처

2010-01-04 00:10:21

제안 된 2 개의 테이블에 동일한 열이있는 경우, 별도의 테이블을 만들어야하는 이유가 없습니다. 고객 유형 (국제 또는 국내)을 저장하기위한 열을 생성하고 그런 식으로 추적하십시오. 왜 1이면 충분합니까?

출처

2010-01-04 01:18:48

기타 답변은 모두 유효합니다.

로컬 고객과 해외 고객을위한 별도의 시퀀스가 필요하다는 것을 알고 있기 때문에 추가하고 싶습니다. 특정 연속 동작에 의존하는 것은 좋지 않은 아이디어입니다. 특히, 식별 컬럼의 경우 삽입이 실패하고 롤백 될 때 갭이 발생할 수 있습니다 (트랜잭션에 대한 ID는 트랜잭션에 즉시 예약되지만 제약 조건이나 트리거가 실패하면 삽입되지 않습니다). 또한 시드와 간격을 변경하고 ID 삽입을 사용하여 비 순차 값을 삽입 할 수도 있습니다.

고객 유형 플래그가있는 유효한 대리 유형 열을 옹호합니다. ID 컬럼은 모든 고객에게 고유합니다. 별도의 시퀀스를 절대적으로 원한다면 트리거를 작성하여 실제 시퀀스를 얻거나 ID를 사용할 수 있습니다. 그런 다음 조합 된 키를 작성하고 필요에 따라 해당 열에 인덱스를 넣으라고 제안 할 때 지속 형 계산 열을 사용할 수 있습니다.

출처

2010-01-04 01:24:49

자동 증가 기능이있는 사용자 정의 PrimaryKey 생성

답변

관련 문제