2017-12-25 17 views
0

외래 키가있는 테이블을 만들어야합니다.SQL Server 외래 키가있는 테이블을 만드는 다른 방법

CREATE TABLE books 
(
    book_id NVARCHAR(15) NOT NULL UNIQUE, 
    author_id INT REFERENCES authors(author_id) 
    ... 
); 

그러나 대학 내 교수가 나에게 외래 키를 다루는 또 다른 방법을 보여주는 모범적 인 스크립트 전송 : 지금까지이 같은 것을하고있다 그 차이를 찾으려고

CREATE TABLE books 
(
    book_id NVARCHAR(15) NOT NULL UNIQUE, 
    author_id INT, 

    CONSTRAINT author_FK 
     FOREIGN KEY(author_id) REFERENCES authors(author_id) 
    ... 
); 

을, 나는 연구를했다. 불행하게도, 난 답을 찾지 못했다, 내가 (두 번째와 매우 유사) 외래 키와 테이블을 생성하는 또 다른 방법이었다 찾았는지 :

CREATE TABLE books 
(
    book_id NVARCHAR(15) NOT NULL UNIQUE, 
    author_id INT, 
    FOREIGN KEY(author_id) REFERENCES authors(author_id) 
    ... 
); 

당신이 그들 모두의 차이점을 수 있을까요?

+0

두 번째 접근법의 한 가지 이점은 제약 조건을 ** 이름 지정 ** 할 ** 있습니다 ** 나중에 삭제하려는 경우 ** 이름 **을 기반으로하기 때문에 훨씬 쉽습니다. ** 제약 조건 **). * 자신의 제약 이름을 명시 적으로 지정하지 않으면 FK 제약 조건이 시스템에서 제공하는 제약 조건 이름을 얻습니다.이 제약 조건 이름은 거의 직관적이지 않으므로 나중에 제약 조건을 훨씬 더 세게 적용 할 수 있습니다. –

답변

1

기능적으로는 두 가지간에 차이가 없습니다. 첫 번째는 인라인 제한 조건이라고하며 (check 제약 조건에도 사용할 수 있습니다).

두 가지 사소한 차이가 있습니다. 첫 번째는 constraint 키워드가 인라인 참조에 필요하지 않으므로 인라인 참조는 제한 조건의 이름을 지정하지 않는 경우가 종종 있습니다 (constraint이 허용되고 이라는 이름으로 참조 할 수 있지만 사용자가 표시하는 구문은 아닙니다).

둘째, 외래 키 참조는 하나의 열만 사용할 수 있습니다. 왜냐하면 저는 거의 항상 복합 기본 키가 아닌 합성 기본 키를 가지고 있기 때문에 이것은 거의 문제가되지 않습니다. 그러나 인라인 구문은 전체 제약 조건 정의보다 덜 강력합니다.

그런데 alter table을 사용하는 세 번째 방법이 있습니다. 이는 두 번째 방법과 비슷하지만 테이블이 이미 생성 된 후에 제약 조건을 추가 할 수 있습니다.