테이블은 UUID를 기본 키로 사용하여 Oracle DB에 CHAR (36)로 저장합니다. 대부분의 테이블에는 모든 언어로 된 NVARCHAR 열이 있습니다. 이 칼럼에서 자연어 정렬을 지원하고 싶습니다. ALTER SESSION을 통해 oracle 세션에서 NLS_SORT와 NLS_COMP를 설정하면됩니다. 내가 부딪히는 문제는 오라클이 UUID 열의 바이너리 인덱스를 사용하지 않고 항상 전체 테이블 스캔을 수행한다는 것입니다.UUID와 Oracle의 NLS_COMP & NLS_SORT 설정 사용
이진 색인을 잃어 버리지 않고 정렬의 장점을 얻으려는가요? 내가 찾은 한 가지 해결책은 UUID를 나타 내기 위해 RAW (16)를 사용하는 것입니다.이 경우 Oracle은 NLS sort/comp에 관계없이 바이너리 인덱스를 사용합니다. 하지만 더 나은 대안이 있기를 바랬습니다.
제안 사항?
모든 세션에 대해 NLS_SORT 및 NLS_COMP를 설정하는 경우 기본 정렬을 사용하려면 인덱스가 실제로 필요합니까? 언어 정렬을 구현 한 function-based index instead을 만들 수 있습니까?
환경을 좀 더 설명 할 수 있습니까?
동일한 열에 다른 언어를 저장하는 경우 언어 정렬의 모든 형태가 방해 받게됩니다. 즉, 프랑스어와 독일어가 혼합되어 있고 '프랑스어'순서 또는 '독일어' 주문)?
왜 NVARCHARs를 사용합니까? 멀티 바이트 문자 집합을 기본값으로 사용하는 경우 VARCHAR은 필요한 문자를 저장합니다.
RAW (16)는 분명히 CHAR (36)보다 훨씬 작으며 UUID의 '기본'형식에 훨씬 가깝습니다 (숫자도 사용할 수 있지만). 16 진수 형식은 더 많은 프리젠 테이션 문제이며 PK (특히 하이픈 포함)로 사용하지 않습니다. 11gR2에서 뷰 또는 가상 (파생 된) 열을 파생시킬 수 있습니다.
특히 다국어 응용 프로그램에서는 CHAR에 UUID를 저장할 때 문자 집합 변환의 위험이 있습니다. 나는 'a', 'b', 'c'와 같은 글자가없는 한국어 또는 중국어로 UUID가 어떻게 보일 지조차 확신하지 못합니다.
저는 하나의 언어 (혼합 없음)로만 정렬하고 있습니다. 언어는 응용 프로그램이 설치 될 때 설정되며 나중에 변경할 수 없습니다. – mahdouch