이 질문은 공급 업체 / 버전에 구애받지 않습니다.
영어를 구사하는 사람 (타이피스트, 작가)으로서, 단어가 올바르게 입력 될 것으로 기대하지만 반드시 올바른 억양이 올바른 방향으로 가고있는 것은 아닙니다.
샹젤리제 식당에서 클로이와 함께 쁘띠 뜨 호텔을 맛 보았고, garcon이 내 볶은 jalapeno 페이트를 가져 오기를 기다리는 동안 ...
당신은 그 아이디어를 얻습니다.
그래서 오늘 나는 대소 문자를 구분하지만 악센트를 구분하지 않는 데이터 정렬을 사용하기 위해 검색 조건을 원했지만 찾지 못했습니다. 이것에 대한 정당한 이유가 있습니까? 아니면 단지 드문 유스 케이스입니까?
다음은 내가보고있는 일부 문서의 예입니다 (벤더 / 버전에 관계없이 생각할 수도 있음).
답변:
TL; DR
콜 레이션에 대한 "공급 업체에 구애받지 않는"관점이나 "버전에 구애받지 않는"관점은 없습니다. 구현에 영향을받지 않는 측면과 이름 지정 규칙을 포함하여 구현은 공급 업체별로 다르며 시간이 지남에 따라 변경되기 때문입니다. .
다음은 내가 찾은 것에 대한 요약이며 세부 사항은 줄 아래의 더 긴 섹션에 있습니다.
RDBMS Naming- Combinations Case-Sensitive and
convention of options? Accent-Insensitive support?
------- ------------ ------------- -----
SQL Server _CS, _AI, etc Yes Latin1_General_100_CS_AI
DB2 _E{x}, _S{y}, etc Yes CLDR181_EO_S1
PostgreSQL locale: en_US N/A unaccent(), not via Collation
MySQL _cs, maybe _ai No No: _cs implies _as & _ci implies _ai
Yes? Create your own Collation :-)
Oracle only _CI & _AI No No: _AI always implies _CI
SAP ASE arbitrary: turdict N/A No: "AI" always implies "CI"
Informix locale.codepage N/A No: no "AI" via Collations차트에서 볼 수 있듯이 7 개의 RDBMS 중 2 개는 기본적으로 "대소 문자 구분 및 이름 지정 규칙 (및 다른 기능적 차이)이 다르지만 데이터 정렬을 통해 문자 악센트 구분없이"조작을 합니다.
하나의 RDBMS (PostgreSQL)는 기본적으로이 조합을 지원하지 않지만 unaccent()애드온 기능으로 악센트를 제거하여이를 달성 할 수 있습니다 .
옵션에 대해 유사한 명명 규칙이있는 마지막 4 개의 RDBMS는 기본적으로이 조합을 지원하지 않으며 악센트 / 분음 부호를 제거하기위한 고유 한 기능을 작성하지 않고이를 달성 할 수있는 수단이없는 것 같습니다. MySQL은 자체 데이터 정렬을 만들 수 있지만 소스 컨트롤에 추가하고이를 테스트 및 배포 프로세스에 통합하여 모든 환경의 모든 서버에 적용 할 수 있어야합니다 (아직도 시원하고 유연한 옵션). . SAP ASE는 SAP 가 추가적인 유니 코드 정렬 순서를 제공 할 수 있지만 제공하고자하는 내용에 대해서는 언급하지 않습니다.
에 관해서:
이것에 대한 정당한 이유가 있습니까? 아니면 단지 드문 유스 케이스입니까?
나는이 답변에 대한 연구를 할 때 MySQL에 대해 대소 문자를 구분하지 않고 악센트를 구분하려는 많은 사람들을 찾았지만 원하는 조합을 요구하는 사람은 거의 없었습니다.
검색 조건에서 대소 문자를 구분하지만 악센트를 구분하지 않는 데이터 정렬을 사용하려고했지만 찾을 수 없었습니다.
...
이 질문은 공급 업체 / 버전에 관계없이
데이터 정렬 스펙을 기반으로하는 RDBMS를 찾는 것이 실제로 의미가 없기 때문에 검색에 실패했습니다. 콜 레이션이 작동하는 방식이 아닙니다. 그리고 공급 업체에 구애받지 않는 방식으로이 접근 방식을 사용하려고하지만 현실적으로는 최소한 우리가 상호 작용하는 부분 인 데이터 정렬이 공급 업체별로 다르며 검색하려는 구성표에 항상 맞지는 않습니다. .
문자열 비교 및 정렬은 매우 복잡하며 이러한 규칙을 수행하는 다른 방법이 있습니다. 한 가지 방법은 하나 이상의 규칙을 고려한 매핑을 갖는 것입니다. 따라서 대소 문자와 악센트에 대한 민감성 및 민감성의 네 가지 조합은 네 개의 개별 매핑과 동일합니다. 예를 들어, MSDN 페이지에서 SQL Server 데이터 정렬 이름 을 보았습니다 . 아래로 스크롤하면 차트의 왼쪽 열이입니다 Sort Order ID. 대소 문자 구분 만 차이가 있더라도 각 데이터 정렬의 ID는 SQL_Latin1_General_Cp1_CI_AS= 52, SQL_Latin1_General_Cp1_CS_AS= 51입니다.
또는 UCA (Unicode Collation Algorithm)를 통해 유니 코드가 제공하는 것과 같은 규칙 기반 일 수 있습니다. 이 방법에서는 기본적으로 모든 문자에 하나 이상의 가중치가 부여됩니다. 그런 다음 각 문화권 / 지역에 해당 가중치를 무시하거나 규칙을 제거하거나 규칙을 추가 할 수 있습니다. 이 알고리즘은 로케일 별 규칙을 고려한 다음 선택한 모든 옵션 (대소 문자 구분 정렬을 수행 할 때 가장 먼저 발생하는 민감도)에 따라 가중치를 조작 할 수 있습니다. 이것이 유니 코드 정렬이 유니 코드가 아닌 정렬보다 약간 느린 이유입니다.
실제로 얼마나 많은 옵션이 있는지 이해하려면 (즉, 실제 복잡성) ICU (International Components for Unicode) 프로젝트에서이 데모를 확인하십시오.
이 지정하는 8 개 별도의 옵션이 있으며, 그들 중 일부는 당신이 (예를 들어 생각되는 데이터 정렬 이름 사양의 여러 요소로 표현 얻을 CS, CI, AS, AI, 등). 변형이 몇 개인 지, 각 조합에 고유 한 ID가있는 매핑 파일 접근 방식을 사용하면 수천 개의 파일이 생성됩니다. 이러한 특정 언어가 변경되거나 버그가 발견 될 때마다 이러한 파일 중 많은 부분을 업데이트해야합니다. 이것이 SQL Server 2012에 이러한 유형의 데이터 정렬 유형이 75 개 (예 :로 시작하는 이름 SQL_) 인 이유 일 수 있습니다 . 따라서에 대한 조합이 없습니다 _CS_AI.
UCA 기반 데이터 정렬에 대한 조합을 찾을 수없는 이유는 무엇입니까? SQL Server 2012에는로 시작하지 않는 3810 개의 데이터 정렬이 SQL_있으므로 총 3885 개의 데이터 정렬이 있습니다. 이 목록은 너무 길어서 웹 페이지에 완전히 열거 될 수 없습니다. 그러나 이것이 다른 공급 업체에 대해이 조합을 찾을 수없는 이유를 완전히 설명하지는 못합니다.
이미 언급 한 것 (즉, 구현하기에는 너무 많은 조합 및 나열하기에는 너무 많은 구현) 외에도 공급 업체별 구현과 경쟁해야합니다. 의미 : 모든 공급 업체가 이러한 옵션을 모두 조정할 수있는 것은 아니며, 처음에는 데이터 정렬에 대한 표준 명명 규칙이 없습니다. 또한 모든 공급 업체가 정렬 옵션을 데이터 정렬의 일부로 보는 것은 아닙니다. PostgreSQL 데이터 정렬은 선택한 로캘의 기본 순서이며 ILIKE대소 문자를 구분하지 않는 비교를 위해 사용해야 합니다. 공급 업체별 정보는 아래를 참조하십시오.
이 두 MSDN 설명서 페이지에 표시되는 내용과 @MartinSmith가 질문에 대한 의견으로 제공 한 쿼리 (아래에서 약간 수정 됨)의 차이점 :
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';이 두 MSDN 페이지는 특히 더 이상 사용되지 않는 SQL Server 데이터 정렬을 참조하는 반면 해당 쿼리의 결과로 표시되는 데이터 정렬 (SQL Server 2012, SP3에서 888 개)은 Windows 데이터 정렬입니다.
SQL Server 2000부터는 이전 SQL Server 데이터 정렬 (SQL Server가 Windows 데이터 정렬을 사용하기 전에 생성됨)이 더 이상 사용되지 않으며 새로운 규칙이나 기능으로 업데이트되지 않습니다. 예를 들어, SQL Server 2012부터 보충 문자에 대한 기본 제공 함수 (예 : UCS-2에 처음 정의 된 "기본"65,536자를 초과하는 나머지 UTF-16 문자)를 올바르게 처리 할 수있는 데이터 정렬 세트가 추가되었습니다. ). 이러한 새로운 데이터 정렬로 끝나는 _SC(같이 S upplementary C의 haracters).
이름이 시작하는 SQL Server 데이터 정렬을 사용 하지 않는 것이 가장 좋습니다 SQL_. 따라서 찾고자하는 옵션 조합 (대소 문자 구분 및 악센트 구분 안 함)을 지원하는 많은 데이터 정렬에 액세스 할 수 있습니다. 가능할 때마다 _SC원하는 다른 옵션이 모두 있는 한 한쪽 끝을 사용하는 것이 가장 좋습니다 .
SQL Server는 _CS_AI명명 규칙을 사용하지만 3810 (SQL Server 2012 기준) Windows 데이터 정렬 목록이 모두 없습니다. 모든 로케일 및 버전과 이름 지정 규칙이 작동하는 방식을 나열 하는 Windows 데이터 정렬 이름 페이지 만 있습니다.
SQL Server는 또한 너비와 가나 감도의 토글을 지원합니다.
MySQL의 버전 5.7, 문서 가 지원 않는 상태는 _ai, _as, _ci, 및 _cs접미사 (그리고 _bin완전성에 대한)뿐만 아니라, 상태 :
악센트 구분을 지정하지 않은 이진 데이터 정렬 이름의 경우 대 / 소문자 구분에 따라 결정됩니다. 데이터 정렬 이름을 포함하지 않는 경우 즉,
_ai나_as,_ci이름에서 알 수 있듯이에서_ai와_cs이름이 의미에서_as.예를 들어,
latin1_general_ci대소 문자를 구분하지 않고 (악센트를 구분하지 않음, 암시latin1_general_cs적으로)
이것은 latin1_general_cs_ai데이터 정렬 이 가능하다는 것을 의미합니다 . 그러나, 나는에 액세스 할 수는 MySQL 5.5.50 서버가 하나 이상의 접미사가 어떤 데이터 정렬이없는, 그리고 (가) 단지 내가 볼 접미사입니다 : _cs, _ci, 및 _bin198 개 총 데이터 정렬에서. SHOW COLLATION 명령을 사용하여 목록을 표시했습니다.
따라서 MySQL이 비슷한 명명 규칙을 사용하는 것처럼 들리지만 (적어도 두 가지 옵션이있는 한) 찾고있는 것과 일치하는 데이터 정렬을 찾을 수 없습니다. 그러나 악센트 (및 기타 발음 구별 부호)를 제거하고 _cs데이터 정렬을 사용하여 원하는 것을 얻을 수 있습니다 (PostgreSQL에서 수행하는 방식과 유사-아래 참조). 그러나 나는이 옵션을 확신하지 못하고 더 이상 연구 할 시간이 없습니다.
또는 원하는대로 정확하게 작업 할 수있는 고유 한 데이터 정렬을 만들 수 있습니다. 다른 RDBMS와 달리 MySQL은 자신의 데이터 정렬을 추가하는 것이 다소 간단 해 보입니다.이 경우 각 문자의 가중치를 완전히 제어 할 수 있습니다. 자세한 내용 은 8 비트 문자 집합에 간단한 데이터 정렬 추가 및 유니 코드 문자 집합 에 UCA 데이터 정렬 추가 를 참조하십시오.
MySQL이 다양한 유형의 데이터 정렬을 처리하는 방법에 대한 자세한 내용은 해당 데이터 정렬 구현 유형 페이지를 참조하십시오.
PostgreSQL의 데이터 정렬은 훨씬 유연하지 않습니다. 당신은 문화 / 로케일을 지정 : en_US, de_DE, 등 자신의 설명서 페이지를 참조하십시오 정렬 지원에 대한 자세한 내용은. 따라서 기본적으로 문화권 별 재정의를 얻지 만 데이터 정렬은 그렇지 않으면 모든 것에 민감합니다 (그런데 "이진"데이터 정렬과 동일 하지 않음 ).
대소 문자를 구분하지 않으려면 ILIKE (섹션 9.7.1)를 사용할 수 있지만 악센트 구분에 대해서는 유사한 연산자가 없습니다. 그러나 악센트 및 기타 발음 구별 부호를 제거하는 데 사용할 수 있는 악센트없는 기능 이 있음을 발견했습니다 . 이 기능은 추가 제공 모듈 이므로 사용할 특정 PostgreSQL 서버에 반드시 존재 하지는 않습니다 . 가장 최근에 링크 된 문서는 다음과 같습니다.
소스 배포판에서 구축 할 때, 이러한 구성 요소는 당신이 "세계"목표를 구축하지 않으면, 자동으로 만들어지는 것이 아니다
...
당신의 PostgreSQL의 사전 패키지 버전을 사용하는 경우, 이러한 모듈은 일반적으로 별도의 서브 패키지로 사용할 수 있습니다 postgresql-contrib.
해당 기능이없고 원하는 경우 해당 기능을 얻는 방법에 대한 지침은 해당 설명서를 참조하십시오.
자세한 내용은 다음 스택 오버플로 답변을 참조하십시오.
PostgreSQL은 "악센트 구분없는"데이터 정렬을 지원합니까?
Microsoft SQL Server와 유사하게 DB2에는 두 가지 유형의 데이터 정렬이 있습니다.
"SYSTEM"데이터 정렬 SYSTEM_{codepage}_[optional-territory]. 다음 형식을 사용하여 지정됩니다 .. 이것들은 매우 유연하지 않으며 케이스, 악센트 또는 기타에 대한 민감도 조정을 지원하지 않는 것으로 보입니다. 지원되는 데이터 정렬 목록은 다음에서 찾을 수 있습니다. 지원되는 지역 코드 및 코드 페이지
UCA (Unicode Collation Algorithm) 기반 데이터 정렬. 이것들은 꽤 많은 조정을 지원합니다. 동작 구성, 명명 규칙 및 유효한 로캘 목록에 대한 자세한 내용 은 해당 유니 코드 데이터 정렬 알고리즘 기반 데이터 정렬 페이지를 참조하십시오. 표 1에서 세 번째 행 ( "케이스 수준")의 예는 다음과 같이 시작합니다.
Case Level 속성을 on으로 설정하고 Strength 속성을 primary 레벨로 설정하면 악센트는 무시되지만 대소 문자는 무시되지 않습니다.
그것이 바로 당신이 찾고 있었던 것입니다. 그러나 그 구문은 다음과 같습니다
CLDR181_EO_S1. 그리고 그래서 검색에서 DB2와 관련된 것을 찾지 못했습니다.
Oracle 10g는 악센트를 구분하지 않는 비교 및 정렬을 지원합니다. 하나:
_CI및_AI_CI여전히 악센트를 구분합니다_AI"대소 문자를 구분하지 않습니다." (아래 링크 된 문서에서 인용)자세한 내용과 예 는 언어 정렬 및 문자열 검색 설명서 페이지를 참조하십시오.
ASE는 각 로케일 / 문자 세트당 다음과 같은 감도 조합 중 하나 이상을 지원합니다.
기본 정렬 순서 선택 페이지 에서 로케일, 문자 세트 및 사용 가능한 정렬 순서 사이의 관계를 확인할 수 있습니다 . 그리고 데이터 정렬 이름 및 ID 페이지 에서 전체 데이터 정렬 목록을 볼 수 있습니다 .
데이터 정렬 이름 지정 규칙은 모두 4-8 자이며 로케일 이름 또는 코드 페이지와 일부 정렬 의미를 캡처하려고 시도한다는 점에서 임의적입니다. 예를 들면 다음과 같습니다.
altnoacc== "CP 850 대안 – 악센트 없음"
rusdict== "러시아어 사전 순서"
dynix== "중국어 음성 순서"
기본 유니 코드 정렬 순서 선택 페이지 에 다음과 같은 메모 가 있습니다.
$/collate/Unicode디렉토리의 외부 파일을 사용하여 정렬 순서를 추가 할 수 있습니다 . 이름과 데이터 정렬 ID는에 저장됩니다syscharsets.syscharsets기본 유니 코드 정렬 순서를 설정하기 전에 외부 유니 코드 정렬 순서의 이름을 입력하지 않아도됩니다 .
...
외부 유니 코드 정렬 순서는 SAP에서 제공합니다. 외부 유니 코드 정렬 순서를 만들려고하지 마십시오.
대소 문자를 구분 하고 악센트를 구분하지 않도록 SAP가 외부 정렬 순서를 제공하는지 여부는 확실하지 않습니다 . 아마 언젠가는 그들에게 이메일을 보내서 요청할 수 있는지 물어볼 것입니다.
원하는 감도 조합을 얻으려면 스칼라 사용자 정의 함수 를 만들어 악센트 및 기타 발음 구별 부호를 제거 할 수 있어야 합니다.
Informix는 대부분 Collation의 기본 정렬 및 비교 동작을 지원하는 것으로 보입니다. 따라서 데이터 정렬은 로캘 및 문자 집합 일뿐입니다. 대 / 소문자 구분은 데이터베이스 수준에서 처리되며 기본적으로 대 / 소문자를 구분합니다. 명령문에 NLSCASE INSENSITIVE 를 지정 하여 데이터베이스 (테이블, 열, 쿼리 또는 술어가 아님)를 대소 문자를 구분하지 않도록 설정할 수CREATE DATABASE 있습니다.
클라이언트 연결별로 데이터베이스 데이터 정렬 (로캘 및 문자 집합)을 재정의 할 수 있지만 대 / 소문자 구분 설정을 재정의하는 방법은 없습니다. 그리고 NLSCASE옵션은 이름에 "NLS"가 있는데 이유는 다음 NCHAR과 같습니다 NVARCHAR. CHAR그리고 VARCHAR항상 대소 문자를 구분합니다.
악센트 감도는 다루어지지 않으며 악센트 / 분음 부호를 제거하는 기본 제공 기능도 없습니다.
Informix 데이터 정렬 이름 지정 규칙은 다음과 같습니다.
<lang>_<country>.<code set>어디:
<lang> = 2 자리 또는 3 자리 언어 코드<country> = 2 자리 국가 또는 지역 코드<code set> = 다음과 같은 3 가지 방법 중 하나로 지정된 코드 페이지 :
따라서 다음 세 가지 로캘 사양은 모두 정확히 동일한 로캘을 나타냅니다.
자세한 내용은 다음을 참조하십시오.
--color깃발을 사용하십시오 . 그러나 JCL을 사용하여 쿼리를 제출하는 경우에만 작동한다고 생각합니다. ;-). 또는 빨간색과 파란색을보고 싶다면이 대답 에 사용 된 이미지로 충분할까요? 그러나 진지한 참고로 : 그 훌륭한 칭찬 😺에 대해 대단히 감사합니다. 또한 방금 SAP ASE에 대한 정보를 추가하고 몇 가지 다른 편집 작업을 수행 했으므로 자세한 내용은 개정 내역 을 참조하십시오.