대리 키가 사용자에게 노출되어야합니까?

종종 자연 키가없는 테이블에서 사용자가 고유하게 생성 된 식별자를 가질 수있는 것이 여전히 유용합니다. 테이블에 대리 기본 키가 있고 (이 경우 확실하게 예상 할 수있는 경우) 해당 키를 사용자에게 노출해야합니까, 아니면 다른 필드를 해당 용도로 사용해야합니까?

대리 키를 표시하지 않는 한 가지 이유는 이제 레코드 간 관계를 유지하는 작업을 수행 할 수 없지만 특정 종류의 삭제 / 재 삽입과 같은 키 값을 변경하고 한 데이터베이스에서 여러 데이터베이스로 데이터를 복사하는 여러 가지 방법을 변경하기 때문입니다. 다른 것 등

대리 키를 노출하면 얻을 수있는 주요 이점은 필드를 간단하게 사용할 수 있다는 것입니다.

어떤 상황에서 대리 키를 사용자에게 직접 노출시키는 것이 더 낫습니까?

변경이 필요한 사용자 / 고객에게 노출되는 식별자에 대한 준비가되어 있어야하며, 데이터베이스에서 행의 ID를 변경하고 해당 변경 사항을 모든 외래 키에 전파하면 데이터가 중단됩니다.

데이터에 자연 비즈니스 키가없는 경우 "비즈니스 식별자"에 대한 추가 필드를 추가 할 수 있습니다. 사용되는 프로세스에 맞게 최적화해야합니다. 전화 키패드 입력은 숫자 만 의미합니다. 전화 / 언어를 통해 유사한 소리 기호 (B / D, M / N 등)를 피하십시오. 기억하기 쉬운 문구 ( "녹색 젤리")를 자동 생성 할 수도 있습니다.

그 결과 비즈니스는 나중에 레코드 참조 방법을 변경할 수 있으며 데이터 스키마 변경은 해당 스타일의 ID에 새 열을 추가하거나 이미 존재하는 ID를 변환하는 것입니다. 변경 사항은 전체 데이터베이스를 통해 전파되지 않으며 시간이 지남에 따라 유효한 하나의 ID (대리인)가 여전히 있습니다.

요컨대, 대리 키를 사용자에게 노출시키지 마십시오. 주석에서 알 수 있듯이 대리 키는 거의 변하지 않아야합니다. 반대로, 기업은 모든 것을 바꾸고 싶어합니다. 대리 키가 노출되면 비즈니스에서 키를 변경하기 전에 시간 문제 일뿐입니다.

부수적으로, 여기서 "노출"이라고 할 때, 사용자가 키를 직접 사용할 것이라는 기대를 가지고 (주문 번호를 지원하기 위해 전화하는 것과 같이) 사용자에게 키를 제공하는 것을 의미합니다 .

경우에 따라 대리 키가 필요하며 사용자에게 의미가 있습니다. 내가 가장 좋아하는 예는 "주문 번호"입니다. 주문 번호는 실제로 자연 키가 아닙니다. 자연 키는 타임 스탬프에 사용자를 더한 것일 수도 있고, 사용자가 타임 스탬프 단위 내에서 둘 이상의 주문을 생성 할 것으로 예상하는 경우에는 그 이상일 수도 있습니다.

그럼에도 불구하고, 사용자 는 주문 번호의 편리함을 이해 하고 기대합니다. 사용자에게 알려 주면 해를 끼치 지 않으며 많은 가치가 있습니다.

반면, 일부 대리 키는 사용자에게 의미가 없습니다. 물론, 건강 보험 회사에는 회원 ID, 생년월일, 이동 통신사 등을 기반으로 나를 식별하는 대리 키가 있지만 그 점에 대해서는 신경 쓰지 않습니다. 저의 고용주와 전 세계적으로 독특하지는 않습니다. 따라서 보험 회사의 대리 키).

제대로 생성 된 GUID / UUID * 인 경우 대리 키만 노출해야합니다. 순차 대리 키 노출 은 OWASP Top 10 보안 문제에서 4 위입니다.

* 실제로 암호로 안전한 난수 또는 의사 난수 생성기에 의해 생성 된 것을 알지 않는 한 이러한 목적으로 제대로 생성되지 않았다고 가정하는 것이 가장 좋습니다.

테이블에 자연 키가없는 경우 서로 게이트 키는 이와 같은 행을 허용합니다.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

대리 키 대신 이러한 인공 키를 호출하지만이 질문에는 그 구별이 중요하지 않습니다.

이제 외래 키를 통해 이러한 대리 키를 참조하는 중요한 데이터가 있다고 가정하면 최종 사용자 는 대리 키 값을 모르는 경우 업데이트 할 행을 어떻게 알 수 있습니까?

평신도의 말로 :

• 대리자는 사용자에게 숨겨져 있어야합니다.
• 다른 비즈니스 후보 키를 사용자에게 공개해야합니다.
• 다른 후보 키가 없으면 PK를 표시해야합니다. 그러나이 경우 PK는 다른 열을 대체하지 않으므로 대리로 간주되지 않습니다.

직접 또는 결함보고시 사용자에게 유용한 정보를 제공하는 필드 만 사용자에게 노출해야합니다.

반대로, 사용자가 수행하는 상호 작용을위한 레코드 (단순 또는 복합)를 식별하는 주요 수단 인 경우 항상 "대리 기본 키"를 공개해야합니다.

키를 최종 사용자에게 공개할지 여부는 중요하지 않습니다. 애플리케이션은 주문 ID를 아는 것만으로도 일반적으로 액세스 할 수 없었던 항목에 대한 액세스를 허용 할 수 없도록 필요한 권한을 수행해야합니다.

경고 : 서버 측 인증이 가능하거나 가능한 웹 기반 또는 n 계층 응용 프로그램을 가정합니다. SQL을 직접 실행하는 VB 앱이 있다면 이는 전혀 다른 문제입니다.