일부 테이블에 대한 데이터베이스에서 보조 기본 키 작성

내 테이블 중 일부에 uuid 또는 임의의 긴 키가 될 "second_primary_key"를 추가하고 싶습니다. 일부 테이블의 경우 웹 응용 프로그램에 정수를 노출하고 싶지 않기 때문에 필요합니다. 즉, "/ invoices"페이지에는 송장 목록과 "/ invoices / : id"에 대한 링크가 있습니다. 여기서 : id는 정수입니다. 사용자가 내 시스템의 송장 수를 알기를 원하지 않으므로 "/ invoices / 123"대신 "second_primary_key"를 사용하여 URL이 "/ invoices / N_8Zk241vNa"가되도록합니다.

실제 ID를 숨기고 싶은 다른 테이블도 마찬가지입니다.

이것이 일반적인 관행입니까? 이것을 구현하는 가장 좋은 방법은 무엇입니까?

그리고이 기술은 결국 무엇을 호출하여 검색 할 수 있습니까?

UUID 열을 추가 할 수는 있지만 실제로는 필요하지 않습니다. 이것은 프리젠 테이션 레이어 문제입니다. 1999 년뿐만 아니라 $ 1,999의 통화 가치를 저장하는 것을 꿈꾸지 않을 것입니다.

응용 프로그램의 값을 즉시 가리는 방법이 필요합니다. 응용 프로그램 자체 또는 데이터베이스보기에서이 작업을 수행 할 수 있습니다.

우리는 단일 값에 대해서만 이야기하기 때문에 AES 또는 이와 유사한 것과 같은 양방향 암호화를 살펴볼 수 있습니다. 더 가벼울수록 좋습니다.

해싱은 또 다른 가능성이 될 수 있습니다. 해싱은 한 가지 방법이므로 송장 번호를 다시 가져올 지 여부에 따라 다릅니다.

"대체 기본 키"는 관계형 데이터베이스 모델링에서 잘 알려진 개념으로, "대체 키"또는 때로는 "보조 키"라고합니다. "잠재적 기본 키"세트를 "후보 키"라고합니다. https://beginnersbook.com/2015/04/alternate-key-in-dbms/를 참조 하십시오

특히 총 레코드 수를 숨기려는 경우이를 구현하는 방법은 전적으로 사용자에게 달려 있습니다. "가장 좋은 방법"은 없습니다. ID를 대 / 소문자를 구분하거나 원하지 않는 경우, 인쇄 된 송장에서 읽을 수있게하려면 허용 또는 유용한 문자 집합, 최대 길이와 같은 요구 사항을 확인해야합니다. 오류없이 전화로 철자를 다시 입력 할 수 있어야합니다.

대부분의 송장에는 송장 번호가 있으며, 대부분의 회계 규칙에 따라 순차적이거나 회계사가 연도 결과에 서명하지 않거나 IRS (또는 귀하의 국가에서 유사한)가 탭에서 전체 감사를 수행 할 수 있습니다.

사용자는 송장 번호에서 서비스를 제공 한 고객 수 또는 송장의 번호 매기기 전략을 변경하기까지의 시간을 추론 할 수 있습니다.

데이터베이스에 저장된 송장 수는 총 송장 총액의 측정치가 아닙니다. 상공 회의소에 연도 보고서 요청을 포함하여 다른 방법을 찾아 낼 수 있습니다.

그러나 사용자 로그인 화면 뒤에 인보이스를 잠그면 모든 사람이 요청할 수있는 것은 아닙니다. 그런 다음 사용자 로그인시 아약스 방법론을 사용하여 미결제 송장을 요청할 수 있습니다. 이렇게하면 데이터가 보호되고, 아약스로 URL이 숨겨집니다 (아약스 요청의 구성 방법에 대한 세부 정보를 보려고하는 사람은 아무도 없습니다) 데이터를 표시하고 제공하는 방법을 제어합니다.

이를 위해 hashids 를 사용할 수 있습니다 .이 시나리오를 정확하게 해결하도록 설계되었습니다.

데이터베이스 ID를 짧은 해시 (YouTube 비디오의 URL과 유사)로 인코딩하므로 테이블에 보조 키를 추가 할 필요가 없습니다.

다른 고유 키를 만들 수 있지만 그렇게해서는 안됩니다. 주어진 이유 때문이 아닙니다. 테이블 크기를 숨기는 간단한 방법이 있습니다.

저장 N_8Zk241vNa비용은 테이블에서 행당 12 바이트, 그리고 인덱스에서 더 많은 비용이 듭니다. 그것은 당신이 필요로하는 것에 꽤 낭비입니다.

정수를 암호화하면 id공간이 필요하지 않으며 런타임에 아무것도 근접하지 않습니다. 사용 방법은 프로그래밍 언어 및 / 또는 데이터베이스에 따라 다릅니다.

AES를 사용하면 128 비트 정수를 얻을 수 있습니다. 이는 base64에서 22자를 의미하며 아마도 원하는 것보다 많을 것입니다. DES 또는 3DES와 같은 블록 크기가 64 인 암호는 원하는대로 11자를 제공합니다.

테이블마다 다른 키를 사용하십시오.

필요한 모든 테이블 크기를 숨기는 경우 모든 테이블에 대해 공통 시퀀스를 사용할 수 있습니다. 여러 테이블에 자주 삽입하는 경우 병목 현상이 발생할 수 있습니다. Hibernate 및 Hi-Lo 알고리즘과 같은 것으로이 문제는 사라집니다.

두 개의 다른 기본 키를 작성하는 IMHO는 불가능합니다. 물론 uuid를 DB에 넣어 현재 기본 키의 "별칭"으로 만들 수 있습니다. 고유 제한 조건을 사용하여 해당 컬럼 위에 인덱스를 넣을 수 있지만 기본 키는 본질적으로 단일 테이블 내의 단일 키입니다. 복합 기본 키가있을 수 있지만 원하는 것은 아닙니다.

그래서 나는 거기에 두는 것이 좋지만 색인 만 가지고있는 것이 좋습니다. PK 및 기타 고유 한 열을 기준으로 데이터를 쿼리하기위한 처리 구성 요소를 만들 수 있습니다. "/ invoices / ..."에 대한 요청을 처리 할 때 매개 변수를 확인하십시오. 정수인 경우 ID를 검색하고 그렇지 않으면 uuid를 검색하십시오. 또는 ID 검색에서 아무것도 찾지 못한 경우 UUID 검색을 대체로 사용할 수 있습니다.

그리고 "무작위"UUID를 생성하는 방법에 대해 : "ID를 가져오고, 상수를 추가하고, 16 진수로 변환"과 같은 것이 아닌 이유는 무엇입니까? ID의 고유성은 uuid의 고유성을 제공하고 16 진수는 정상적인 필사자에게는 읽기가 어렵고 상수를 추가하면 00000001과 같은 uuid를 피할 수 있습니다.

두 키가 같은 사실을 가리키면 결코 충돌하지 않습니다. 원래 키의 사용자 지정 해시 코드를 생성하는 스칼라 함수를 사용하여 원래 키에서 다른 키를 파생시키지 마십시오.

또는 두 버전의 키를 모두 저장하는 부록 매핑 테이블을 만들 수 있습니다. 이 테이블은 보조 키를 조회하기위한 사전 역할을합니다.

내 이해에 따르면 키는 암시 적 인덱스이며 인덱스를 많이 추가할수록 삽입 속도가 느려집니다.

특정 사용 사례에 대한 또 다른 접근 방법은 데이터베이스와 응용 프로그램을 수정하는 대신 송장에 대한 사용자 지정 경로를 만들어서 / invoices / : f (id) 여기서 f (id)가 id의 일부 기능이라는 것입니다.

사용자 정의 경로는 요청을 올바른 조치 서버 측에 맵핑해야합니다.

'대체 키'(AK)라고도하는 완전히 허용되는 방법입니다. 기본적으로 AK는 다른 고유 인덱스 또는 고유 제약 조건입니다.

AK를 기반으로 외래 키 제약 조건을 만들 수도 있습니다.

가능한 유스 케이스는 설명과 같습니다. 계속 증가하는 ID 번호에 클러스터 된 PK가 있지만 간단히 추측 할 수 있기 때문에이 번호가 검색 기준으로 표시되거나 사용되기를 원하지 않습니다. 또한 AK로 임의의 고유 식별자 또는 참조 번호가 있으며 이는 사용자에게 제시 한 ID입니다.

여러 종류의 키 / 인덱스가 있습니다. 기본 키는 특별한 고유 인덱스이며, 답변에 따르면 다른 고유 키를 만들 수 있습니다. 그리고 정당한 사유가없는 한 데이터베이스 내부를 공개하지 않는 것이 가장 좋습니다.

이 질문은 송장 및 번호와 관련되어 있으므로 회계 업계에서 송장 번호가 어떻게 보이는지 조사하는 것이 좋습니다. http://smallbusiness.chron.com/assign-invoice-numbers-52422.html

기본 키인 내부 ID가 있고 응용 프로그램 / 고객이 볼 수있는 송장 번호가있는 다른 고유 한 필드를 갖는 것이 지저분 해 보일 수 있습니다. 그러나 고객이 새로운 인보이스 번호 매기기 체계를 채택하려고한다고 할 때 그리 불쾌하지 않습니다. 이 경우 왁스의 전체 공의 번호를 다시 매기기 위해 다른 테이블의 내부 ID와의 관계를 방해하지 않습니다. 내부 ID는 그대로 유지하고 비 내장 송장 번호를 다시 매 깁니다.

이상적으로는 변경 될 가능성이있는 키 / 외부 키에 테이블을 묶지 않고 내부 테이블과 관계를 앱 계층에 투명하게 유지하려고 노력합니다.

해봐

이는 블로그 기사 등이 자주 사용하는 "슬러그"필드와 다르지 않습니다. URL에서 사용하기에 적합한 기본 키와 별도로 데이터베이스 레코드를 참조하는 고유 한 방법입니다. 나는 누군가가 그것에 대해 논쟁하는 것을들은 적이 없다.