에 대한 조회 내 사용자 테이블이 (의사 SQL을 나는 ORM을 사용하고 난 여러 다른 DB 유형을 지원해야하기 때문에) 나는 현재 다른 모든 테이블에 FK에 대한 ID를 사용하고SQL : UUID
id: INTEGER, PK, AUTOINCREMENT
UUID : BINARY(16) (inserted by an update, it's a hash(id))
을 . 그러나 내 REST API에서는 UUID를 사용하여 정보를 제공해야하므로 나중에 쿼리 할 때 문제가 발생합니다.
해야하는 I : 대신 UUID에
일반적으로 다른 고유 한 열의 조합이 아닌 외래 키 참조에 자동 증가 ID를 사용하는 것이 좋습니다.
한 가지 중요한 이유 중 하나는 단일 정수의 인덱스가 다른 열 유형의 인덱스보다 더 효율적이라는 것입니다. 인덱스가 작은 것보다 다른 이유로 디스크가 적게 차지하고 메모리가 적 으면. 또한 보조 테이블에 더 긴 UUID를 저장하는 데 추가 오버 헤드가 있습니다.
이것은 유일한 고려 사항은 아닙니다. 또 다른 고려 사항은 필요한 경우 외래 키 참조를 변경하지 않고 UUID를 변경할 수 있다는 것입니다. 예를 들어, 하루를 깨우고 "이드는 AAA로 시작해야합니다"라고 말할 수 있습니다. 당신은 테이블을 변경하고 테이블을 업데이트 할 수 있습니다. 그렇지 않으면 외래 키 참조에 대해서도 걱정할 수 있습니다. 또는 조직 열을 추가하고 고유 키가 UUID와 조직의 조합인지 결정할 수 있습니다. 이러한 작업은 UUID가 외래 키 참조로 사용되는 경우 훨씬 더/더 느립니다.
복합 기본 키 (두 개 이상의 열)를 사용하는 경우 자동 증가 ID를 사용하는 것이 더 좋습니다. 이 경우 조인에 id를 사용하면 조인 조건 중 하나가 생략 될 수있는 실수를 방지 할 수 있습니다.
주어진 ID에 대해 UUID를 찾는 작업은 올바른 인덱스로 빠른 작업이어야합니다. ID를 갖고 싶지 않은 경계선이있을 수 있지만 일반적으로 좋은 생각입니다.
당신은 두 번째 옵션으로 갈 수 있습니다. 정말로 속도가 걱정된다면 ..index ur id와 uuid는 함께 있습니다. 데이터 모델의 무결성을 만지는 것이 좋지 않습니다. FK는 FK .. 렛! – Neels