고유 제약 조건에 대한 명명 규칙
명명규칙은 중요하며 프라이머리 키와 외부 키는 일반적으로 사용되며 명백한 규칙을 가지고 있습니다(PK_Table
그리고.FK_Table_ReferencedTable
(각각).그IX_Table_Column
인덱스에 대한 명명도 상당히 표준적입니다.
UNIQURE 제약은 어떻습니까?이 제약조건에 대해 일반적으로 허용되는 명명규칙이 있습니까?본 적이 있다UK_TableName_Column
,UQ_TableName_Column
, 및 추천하는 사람AX_TableName_Column
- 그게 어디서 왔는지 모르겠어.
저는 보통UQ
하지만 나는 그것을 특별히 좋아하지 않고, 그것을 사용하는 나의 선택을 방어하는 것을 즐기지 않는다.UK
옹호하다
가장 일반적인 명칭에 대한 공감대가 있는지, 아니면 왜 어떤 것이 다른 것보다 더 말이 되는지에 대한 좋은 논리가 있는지 보고 싶을 뿐입니다.
색인 및 제약 조건에 대한 내 명명 규칙:
색인/구속조건 유형 | 명명 규칙 |
---|---|
프라이머리 키 | <테이블명>_PK |
고유 인덱스/제약 | <테이블명>_AK{xx} |
고유하지 않은 지수 | <테이블명>_IX{xx} |
제약조건 확인 | <테이블명>_CK{xx} |
디폴트 제약 | <테이블명>_DF{xx} |
외부 키 제약 | <테이블명>_FK{xx} |
어디에{xx}
는 테이블별 제약조건 유형별로 01부터 시작하는2자리 시퀀스 번호입니다.프라이머리 키에는 시퀀스 번호가1개만 있을 수 있기 때문에, 시퀀스 번호는 취득되지 않습니다.2 문자 알파벳 서픽스의 의미는 다음과 같습니다.
서픽스 | 의미. |
---|---|
PK |
프라이머리 키 |
AK |
대체 키 |
FK |
외부 키 |
IX |
IndeX |
CK |
쳇 |
DF |
결함 |
일반적으로 메타데이터/시스템 카탈로그 데이터를 개체 유형이 아닌 제어 개체별로 그룹화합니다.
내 생각에 그것은 열쇠가 아니라 제약이다.
물론 키로 사용할 수 있고 행을 고유하게 식별하지만 키가 아닙니다.
예를 들어 키가 ThingName 자연 키 대신 사용되는 대리 키인 "ThingID"인 경우가 있습니다.ThingName은 여전히 제한해야 합니다. 단, 키로 사용되지 않습니다.
UQ 및 UQC(클러스터된 경우)도 사용합니다.
대신 고유 인덱스를 사용하여 "IXU"를 선택할 수 있습니다.채택된 논리에 따르면 인덱스는 키이기도 하지만 고유할 때만 키입니다.그렇지 않으면 색인입니다.그래서 우리는 먼저IK_columnname
고유 인덱스 및IX_columnname
참조할 수 있습니다.훌륭해.
고유한 제약 조건과 고유한 인덱스의 유일한 차이점은 INCLUDE 열입니다.
편집 : 2013년 2월SQL Server 2008 이후 인덱스에는 필터도 포함될 수 있습니다.제약은 할 수 없다
그래서 결론부터 말하자면
- SQL을 사용하는 나머지 지역과 마찬가지로 UQ를 준수합니다.
- 일관성을 유지하기 위해 고유 인덱스에 IK 사용(클러스터된 인덱스에 대해서도 IKC 사용)...
UQ를 사용합니다.영국의 K는 PK와 FK에서 사용되는 K를 생각나게 합니다.음, 어쨌든 영국을 생각해 보면, 아이러니하게도, 영국에서는 다른 많은 어소시에이션이 등장하고 있는데, 이것이 유니크(UNIQURIK)의 프레픽스가 되어 버리는군요=)
언급URL : https://stackoverflow.com/questions/4836391/naming-convention-for-unique-constraint
'itsource' 카테고리의 다른 글
생년월일과 getDate()를 기준으로 나이(년)를 계산하는 방법 (0) | 2023.04.07 |
---|---|
현재 데이터베이스 백업이 없으므로 백업 로그를 수행할 수 없습니다. (0) | 2023.04.07 |
SQL-Server:백업 세트는 기존 데이터베이스 이외의 백업을 보유하고 있습니다. (0) | 2023.04.07 |
Lookup()과 Dictionary(Of list)의 차이점 (0) | 2023.04.07 |
마지막으로 삽입된 행 ID 가져오기(SQL 문 포함) (0) | 2023.04.07 |