꼭 필요한 것은 아니지만 테이블에 고유 제한 조건을 사용해야합니까?

Question

Microsoft SQL Server에서 테이블을 만들 때 실제로 고유하지 않아도 고유 제한 조건을 사용하면 단점이 있습니까?

예로는 사용자 관리 시스템의 역할을 말에 대한 설명은 다음과 같습니다

CREATE TABLE Role 
(
    ID TINYINT PRIMARY KEY NOT NULL IDENTITY(0, 1), 
    Title CHARACTER VARYING(32) NOT NULL UNIQUE, 
    Description CHARACTER VARYING(MAX) NOT NULL UNIQUE 
) 

내 두려움이 다른 테이블에 자주 삽입을 수행 할 때이 제약 조건을 검증하는 것은 매우 시간이 많이 걸리는 과정이 될 것입니다. 이 제약 조건이 어떻게 검증되는지는 확신 할 수 없지만 매우 효율적인 방법으로 또는 선형 비교로 수행 할 수있는 것처럼 느껴집니다.

Answer 1

두려움이 사실이됩니다. UNIQUE 제약 조건은 인덱스로 구현되며 이는 시간과 공간을 소모합니다.

따라서 새 행을 삽입 할 때마다 데이터베이스는 테이블을 업데이트해야하며 각 고유 제한 조건에 대해 하나의 인덱스도 업데이트해야합니다.

그래서, 당신에 따라 :

열에 고유 제한 조건을 사용하여 당신이 정말로 대답은 '아니오'

, 사용하지 않는 고유 할 필요하지 않더라도 그것. 시간과 공간의 단점이 있습니다.

샘플 테이블에는 Id에 대한 클러스터 된 인덱스와 각 고유 제한 조건에 대한 2 개의 추가 인덱스가 필요합니다. 이것은 공간을 차지하고 삽입물에있는 3 개의 인덱스를 업데이트하는 데 걸리는 시간입니다.

이러한 필드로 필터링 된 쿼리를 만든 경우에만 유효합니다. 그런데

: 원래 포스트 샘플 표는 몇 가지 결함이 있습니다

• 구문은 SQL 서버 구문이 아님을 (당신은 SQL 서버로이 태그)

• 당신은 만들 수 없습니다 포함 된 VARCHAR (최대)의 인덱스 열

당신이 구문을 수정하고이 테이블을 작성하는 경우 :

CREATE TABLE Role 
(
    ID tinyint PRIMARY KEY NOT NULL IDENTITY(0, 1), 
    Title varchar(32) NOT NULL UNIQUE, 
    Description varchar(32) NOT NULL UNIQUE 
) 

그러면 sp_help Role을 실행할 수 있으며 3 개의 색인을 찾을 수 있습니다.

Answer 2

데이터베이스는 UNIQUE 제약 조건을 백업하는 인덱스를 생성하므로 고유성 검사를 수행하는 데는 매우 비용이 적게 듭니다.

http://msdn.microsoft.com/en-us/library/ms177420.aspx

데이터베이스 엔진은 자동으로 UNIQUE 제약 조건의 고유성 요구 사항을 적용 할 수있는 UNIQUE 인덱스를 생성합니다. 따라서 중복 행을 삽입하려고하면 데이터베이스 엔진이 UNIQUE 제약 조건을 위반했으며 행을 테이블에 추가하지 않는다는 오류 메시지를 반환합니다. 클러스터 된 인덱스를 명시 적으로 지정하지 않으면 기본적으로 고유 한 비 클러스터형 인덱스가 만들어져 UNIQUE 제약 조건이 적용됩니다.

Answer 3

SQL Server에서 데이터 형식 tinyint는 256 개의 고유 한 값만 제공합니다. id 컬럼 밖에서 무엇을 하든지 관계없이 매우 큰 테이블로 끝나지 않을 것입니다. 열 개의 인덱싱 된 열이 있어도 신속하게 수행 할 수 있습니다.

대개 대리 키 외에 하나 이상의 고유 제한 조건이 필요합니다. 네가 가지고 있지 않다면, 이런 식으로 끝내야 할 것이다.

1 First title First description 
2 First title First description 
3 First title First description 
... 
17 Third title Third description 
18 First title First description 

이와 같은 데이터를 허용하는 테이블은 대개 잘못되었습니다. 테이블에 대한 외래 키 참조를 사용하는 테이블은 사용 된 "First title"의 수를 정확하게보고 할 수 없습니다.

나는 사용자 관리 시스템에서 역할에 대해 여러 개의 동일한 제목을 허용하는 것이 디자인 오류라고 주장합니다. 나는 아마 "제목"이 그 칼럼에 대한 정말 나쁜 이름이라고 주장 할 것입니다.

Answer 4

그것은 좋은 연습은 데이터 항상 고유합니다 알고있는 경우를 제한하는 일반적이지만 반드시 제대로 작동하려면 응용 프로그램에 대한 고유 할 필요가 없다?

내게 묻는 질문 : 두 가지 역할이 서로 다른 제목이지만 동일한 설명을 갖는 것이 합리적입니까? 예 :

INSERT INTO Role (Title , Description) 
    VALUES ('CEO' , 'Senior manager'), 
      ('CTO' , 'Senior manager'); 

내게는 설명의 사용을 평가 절하 한 것으로 보입니다. 많은 중복이 있다면 그것은이 같은 뭔가 더 할 더 의미 할 수 있습니다

INSERT INTO Role (Title) 
    VALUES ('CEO'), 
      ('CTO'); 

INSERT INTO SeniorManagers (Title) 
    VALUES ('CEO'), 
      ('CTO'); 

을하지만 다시 당신은 중복을 기대하지 않습니다.

낮은 활동도 테이블이라고 가정합니다. 다른 테이블에서 빈번한 삽입을 할 때이 제약 조건의 유효성을 두려워한다고 말합니다. 우리가 볼 수없는 트리거가 없으면 다른 테이블이 업데이트 될 때이 테이블을 업데이트 할 수 있습니다.

저는 개인적으로 고유 한 제약 조건을 적용하지 않는 것을 정당화하기 위해 디자이너 (비즈니스 분석가)에게 질문 할 것입니다. 그들이 할 수 없다면 나는 상식에 기초한 unqiue 제한을 부과 할 것입니다. 그러한 텍스트 열에 대해서는 보통 그렇듯이, 나는 또한 CHECK 제약을 적용 할 것이다. 선행/후행/이중 공백, 길이가 0 인 문자열 등을 허용하지 않습니다.