0

제 작업 환경에서는 SQL Server에서 정의한 '기본 키'를 사용하지 않습니다. 즉, 열을 마우스 오른쪽 단추로 클릭하고 "기본 키로 설정"을 선택하지 않습니다.기본 키를 정의하지 않고 SQL 데이터베이스 작성

그러나 여전히 기본 키가 있지만 고유 ID 열만 사용합니다. 저장 프로 시저에서 우리는 관계형 데이터베이스에서와 같이 데이터에 액세스하는 데이 메서드를 사용합니다.

내 질문은 SQL Server에서 Entity Framework 등의 기본 키 정의와 함께 제공되는 기본 제공 기능 외에도 고유 ID 열을 사용하는 것보다 '기본 키'기능을 사용해야하는 좋은 이유가 있습니까? 자신의 저장 프로 시저에있는 테이블을 사용하여 테이블에 액세스 할 수 있습니까?

가장 큰 단점은 Entity Framework와 같은 것을 사용하는 것 외에는 ID가 어떤 테이블과 관련되어 있는지를 정신적으로 추적하거나 추적해야한다는 것입니다.

+0

* 데이터베이스에서 ID 열의 고유성을 적용합니까? –

+3

열을 기본 키로 정의하지 않으면 기본 키가 없습니다. 너희들 농담이야. 논리적 기본 키가 있지만 어떤 이유로 참조 무결성을 우회합니다. 기본 키 사용에는 단점이 없습니다. 합리적인 명명 규칙을 사용하는 경우 암기가 없어야합니다. 이는 열이 테이블간에 이름을 변경하지 않는다는 것을 의미합니다. –

+0

https://stackoverflow.com/questions/840162/should-each-and-every-table-aave-a-primary-key –

답변

1

는 질문에 대한 철학적, 실제적인 답변이 있습니다.

답 : 기본 키 제약 조건을 사용하면 "not null"및 "unique"이 적용됩니다. 이것은 응용 프로그램 수준의 버그로부터 당신을 보호합니다.

철학 대답은 개발자가 가능한 한 가장 높은 추상화 수준에서 작동하여 문제 해결을 시도 할 때 두뇌의 세부 사항을 가득 채울 필요가 없다는 것입니다.

기본 키와 외래 키는 기본 데이터 모델에 대한 가정을 허용하는 추상화입니다. 우리는 (사업) 실체와 그 관계에 관해 생각할 수 있습니다.

작업장에서 개발자는 테이블, 색인 및 규칙에 관해 생각해야합니다. "고객", "주문"및 "품목"에 대해 더 이상 생각하지 않고 해당 비즈니스 엔티티를 나타내는 소프트웨어 산출물에 대해 생각합니다. "우리는 항상 GUID와 고유 인덱스의 조합으로 고유성을 나타냅니다. 그 정신 모델은 대부분의 어플리케이션에서 이미 복잡합니다. 새로운 개발자를 팀에 참여시킬 때 더욱 힘들어집니다.

+0

키는 다른 속성보다 더 이상 추상화되지 않습니다. 대부분/대부분의 경우 키는 비즈니스 규칙의 매우 직접적이고 자연스러운 구현입니다. InvoiceNumber 키가있는 송장 테이블은 각 송장에 고유 번호가 있어야하는 비즈니스 규칙을 구현합니다. EmailAddress에 키가있는 사용자 테이블은 사용자가 고유 이메일 주소를 가져야한다는 규칙을 구현합니다.개발자가 엔티티와 그 관계에만 관심이 있다면 각 엔티티에 적어도 하나의 키가 있음을 알아야합니다. 키의 "소수성"은 기본적으로 논리적/개념적 측면에서 관련이 없습니다. – sqlvogel

2

단점은 기본 키를 전혀 사용하지 않고 뭔가 의도하지 않은 고유 한 키 제약 조건을 사용하고 있다고 생각합니다.

고유 키 : 많은 키를 가질 수 있습니다. 행 간의 고유성을 판별하는 방법을 제공하기위한 것입니다.

기본 키 : 하이랜더와 마찬가지로 하나만있을 수 있습니다. 이것은 테이블의 행을 식별하는 용도로 사용됩니다.

기본 키를 사용하지 않을 이유가 없다고 생각합니다. 내 의견은 기본 키가 없으면 테이블이 실제로 테이블이 아니라는 것입니다. 그것은 단지 데이터의 덩어리입니다.

추가 작업 : 나를 믿지 않으면 DBA의 무리에게 기본 키를 사용하지 않는 것이 좋을지 묻는이 사람을 확인하십시오.

Is it OK not to use a Primary Key When I don't Need one

+0

순수한 관점에서, 하나의 키를 가져 와서 다른 키보다 "위"라고 선언하는 것은 불필요한 것처럼 보입니다. 각 후보 키는 고유 키로 선언 될 수 있으며 다른 모든 SQL 기능은 PK를 선언하지 않고도 잘 작동합니다. –

+1

실제 기본 키는 모든 키 열이 'NULL'값을 허용하지 않는다는 규칙을 적용합니다. 고유 제한 조건 및 색인은 널 (NULL) 입력 가능 컬럼을 허용합니다. –

+0

링크 된 질문은 "PK 대 키 없음"의 줄을 따라있는 것 같습니다. 내가 말했듯이, 순수한 관점에서 질문이 "PK vs other keys"인 경우 [이 대답] (https://stackoverflow.com/a/3466460/15498)에서 좀 더 자세히 설명합니다. –

2

PRIMARY KEY 제약 조건에 "특별한"것은 없습니다. 이는 유일성 제약 조건이며 UNIQUE NOT NULL 구문을 사용하여 키를 대신 정의함으로써 동일한 결과를 얻을 수 있습니다.

그러나 고유성 제약 조건 (즉, 일반적으로 "기본"키가 아닌)은 데이터 무결성을 이유로 매우 중요합니다. 데이터가 고유하다는 것은 데이터에서 합리적이고 의미있는 결과를 도출 할 수 있음을 의미합니다. 중복 데이터가 포함 된 데이터베이스에서 정확한 결과를 얻는 것은 매우 어렵습니다. 또한 테이블간에 참조 무결성을 적용하려면 고유성 제약 조건이 필요하며 이는 데이터 무결성의 또 다른 매우 중요한 측면입니다. 불량 데이터 무결성은 매년 비즈니스에 수십억 달러의 손실을 초래하는 데이터 관리 문제이며 이는 키가 중요한 이유입니다.

고유 한 인덱스이 중요한 이유는 쿼리 최적화 및 성능입니다. 고유 색인은 조회 성능을 향상시킵니다. 데이터가 unqiue로 가정되면 고유 인덱스를 작성하면 u 리 옵티마이 저가 u 리를위한 좋은 실행 플랜을 선택할 수있는 최상의 기회를 제공합니다.

관련 문제