다국어 지원¶

문자 데이터¶

콜레이션을 적용할 수 있는 데이터의 타입은 VARCHAR, CHAR, ENUM 타입이다.

문자셋(charset, codeset)은 어떤 타입에 대해 문자가 저장되는 방식 또는 일련의 바이트가 하나의 문자를 구성하는 방식을 제어한다. CUBRID는 UTF-8, ISO-8859-1, EUC-KR 문자셋을 지원하며, UTF-8에 대해 코드포인트 10FFFF(4 바이트까지 인코딩됨)까지만 지원한다. 예를 들어, 문자 "Ç"는 코드셋 ISO-8859-1에서 1 바이트(C7)으로 인코딩되지만, UTF-8에서는 2 바이트(C3 87)로 인코딩된다. 반면, EUC-KR에서 이 문자는 사용할 수 없다.

콜레이션은 문자를 비교하는 방법을 결정한다. 사용자는 흔히 클레이션을 통해 대소문자를 구분하지 않거나 구분한다. 예를 들어 "ABC"와 "abc"는 대소문자 구분 무시(case insensitive) 콜레이션에서는 동일한 반면, 대소문자 구분(case sensitive) 콜레이션에서는 동일하지 않다. 또한 콜레이션에 따라 비교 결과가 "ABC" > "abc"가 되거나 "ABC" < "abc"가 될 수 있다.

콜레이션은 대소문자 비교 이상의 것을 의미한다. 콜레이션은 두 문자열 간에 관계를 결정하여 LIKE와 같은 문자열 매칭에 사용되거나 인덱스 스캔에서 영역을 계산하는데 사용된다.

CUBRID에서 콜레이션은 문자셋을 포함한다. 예를 들어, "utf8_en_ci"과 "iso88591_en_ci"은 대소문자를 구분하지 않는 비교이지만 다른 문자셋에서 동작한다. ASCII 범위에서 비교 결과는 비슷하지만 UTF-8 인코딩은 가변적인 바이트 수에 따라 동작해야 하기 때문에 "utf8_en_ci" 콜레이션에서 비교 수행 속도가 더 느리다.

• 'a' COLLATE iso88591_en_ci는 _iso88591'a' COLLATE iso88591_en_ci를 나타낸다.
• 'a' COLLATE utf8_en_ci는 _utf8'a' COLLATE utf8_en_ci를 나타낸다.

모든 문자 데이터 타입은 자릿수(precision)를 지원한다. 고정 길이 문자(CHAR)는 특별히 다루어져야 한다. CHAR 타입의 값은 자릿수를 채워서 저장된다. 예를 들어 "abc"를 CHAR(5) 칼럼에 저장하면, "abc "(2 개의 공백 문자가 패딩됨)를 저장하게 된다. 공백 문자(ASCII 32, Unicode 0020)는 대부분 문자에서 사용하는 패딩 문자이다. 하지만 EUC-KR 문자셋에서 패딩 문자는 두 개 바이트(A1 A1)로 저장된 하나의 문자로 구성된다.

관련 용어¶

• 문자셋(character set) : 기호를 인코딩(어떤 기호에 특정 번호를 부여)한 집합

• 콜레이션(collation) : 문자셋에서 문자를 비교하기 위한, 데이터 정렬을 위한 규칙의 집합

• 로캘(locale) : 사용자의 언어 및 국가에 따라 숫자 형식, 캘린더(월의 이름, 요일의 이름), 날짜/시간 형식, 콜레이션, 통화 등을 정의하는 인자들의 집합. 로캘은 언어에 대한 지역화(localization)를 정의한다. 로캘의 문자셋은 월의 이름 및 다른 데이터가 어떻게 인코딩되는지를 나타낸다. 로캘은 최소한 하나의 언어 식별자와 영역 식별자로 구성되어 있으며 language[_territory][.codeset]으로 표현한다. (예를 들어 UTF-8 인코딩을 쓰는 오스트레일리아 영어는 en_AU.utf8로 표기한다.)

• 유니코드 정규화(Unicode normalization) : 모양이 같은 여러 문자들이 있을 경우 기준에 따라 이를 하나로 통합하는 것. CUBRID는 입력 시에는 NFC(Normalization Form C) 형식(분해된 코드 코드포인트에서 결합된 코드포인트로 변환)을 사용하고, 출력 시에는 NFD(Normalization Form D) 형식(결합된 코드포인트에서 분해된 코드포인트로 변환)을 사용한다. 하지만, CUBRID는 예외적으로 규범적 등가(canonical equivalence) 규칙을 적용하지 않는다.

  예를 들어, 일반적인 NFC 규칙에 따르면 규범적 등가 규칙을 적용하여 코드포인트 212A(캘빈 기호 K)는 코드포인트 4B(ASCII 코드 대문자 K)로 변환된다. CUBRID는 규범적 등가 규칙에 의한 변환을 수행하지 않도록 하여 정규화 알고리즘을 더 간단하고 빠르게 하였고, 따라서 역변환도 수행하지 않는다.

• 규범적 등가(canonical equivalence) : 시각적으로 구별이 불가능하고 텍스트 비교상 정확히 동일한 의미를 가지는 문자. 한 예로 'A'에 옹스트롬(Angstrom) 기호가 있는 'Å'가 있는데, 'Å'(유니코드 U+212B)와 라틴어 'A'(유니코드 U+00C5)는 모양이 같고 코드포인트가 다르지만 분해된 결과는 'A'와 U+030A로 같으므로 규범적 등가이다.

• 호환성 등가(compatibility equivalence) : 동일한 문자나 문자 시퀀스의 대체 표현 문자. 예로는 숫자 '2'(유니코드 U+0032)와 위첨자 '²'(유니코드 U+00B2)가 있는데, '²' 는 숫자 '2'의 다른 형태이긴 하지만 시각적으로 구별되고 의미도 다르기 때문에 규범적 등가에 해당되지 않는다. '2²'를 NFC로 정규화하면 규범적 등가를 사용하기 때문에 '2²'가 유지되지만, NFKC 방식에서는 '²'가 호환성 등가인 '2'로 분해된 후 결합되어 '22'로 바뀔 수 있다. CUBRID의 유니코드 정규화에서는 호환성 등가 규칙도 적용하지 않는다.

유니코드 정규화에 대한 설명은 유니코드 정규화 를 참고하며, 보다 자세한 내용은 http://unicode.org/reports/tr15/를 참고한다.

유니코드 정규화 관련 시스템 파라미터에서 기본으로 설정되는 값은 unicode_input_normalization=no이고 unicode_output_normalization=no이다. 이 파라미터에 대한 보다 자세한 설명은 구문/타입 관련 파라미터 를 참고한다.

로캘 속성¶

로캘은 다음과 같은 속성들로 정의된다.

• 문자셋(코드셋) : 여러 바이트를 하나의 문자로 해석하는 방법을 정의한다. 유니코드에서는 여러 개의 바이트가 하나의 코드포인트(codepoint)를 구성하는 것으로 해석된다.
• 콜레이션(collation) : LDML(UNICODE Locale Data Markup Language) 파일의 로캘 데이터에 여러 콜레이션을 지정할 수 있는데, 이 중에 마지막으로 명시된 것이 기본 콜레이션으로 사용된다.
• 알파벳(대소문자 규칙) : 하나의 로캘 데이터는 테이블 이름, 칼럼 이름과 같은 식별자용과 사용자 데이터용으로 최대 두 종류의 알파벳을 가질 수 있다.
• 캘린더 : 요일 이름, 월의 이름, 오전/오후(AM/PM) 표시
• 숫자 표기 : 자릿수 구분 기호, 소수점 기호, 통화 형식
• 텍스트 변환 데이터 : CSQL 콘솔 변환용 선택 사항
• 유니코드 정규화 데이터 : 모양이 같은 여러 문자들이 있을 경우 이를 기준에 따라 하나의 값으로 통합하는 정규화를 수행하여 변환된 데이터. 정규화 이후에는 로캘이 달라도 모양이 같은 문자는 같은 코드값을 가지며, 각 로캘은 이 정규화 기능을 활성화 또는 비활성화할 수 있다.

콜레이션 속성¶

콜레이션(collation)은 문자열의 비교 및 정렬 규칙의 집합으로, CUBRID에서 콜레이션은 다음과 같은 속성(property)을 갖는다.

• 세기(strength) : 기본 비교 항목들(문자들)이 어떻게 다른지 나타내는 측정 기준이다. 이것은 선택도(selectivity)에 영향을 준다. LDML 파일에서 콜레이션의 세기는 네 가지 수준(level)으로 설정할 수 있다. 예를 들어, 대소문자 구분이 없는 콜레이션은 level = "secondary" (2) 또는 "primary" (1)로 설정해야 한다.
• 확장(expansion) 과 축약(contraction) 지원 여부

각각의 칼럼이 콜레이션을 가질 수 있기 때문에, LOWER(), UPPER() 함수 등을 적용할 때 해당 콜레이션의 기본 언어에서 정의한 로캘의 대소문자 구분 규칙(casing rule)이 사용된다.

콜레이션 속성에 따라 일부 콜레이션에서 다음과 같은 특정 CUBRID 최적화가 동작하지 않을 수 있다.

• LIKE 구문 재작성: 같은 가중치(weight)에 여러 개의 다른 문자를 매핑하는 콜레이션, 예를 들어 대소문자 구분이 없는 콜레이션에서는 LIKE 구문이 재작성되지 않는다.
• 커버링 인덱스 스캔: 같은 가중치에 여러 개의 다른 문자를 매핑하는 콜레이션에서는 커버링 인덱스 스캔이 동작하지 않는다(커버링 인덱스 참고).
• prefix 인덱스: 확장이 있는 콜레이션을 사용한 칼럼에서는 prefix 인덱스를 생성할 수 없다.

이에 관한 보다 자세한 설명은 콜레이션 설정으로 인한 영향 을 참고하면 된다.

콜레이션 명명 규칙¶

콜레이션 이름은 다음 규칙을 따른다.

<charset>_<lang specific>_<desc1>_<desc2>_...

• <charset>: 문자셋 이름. iso88591, utf8, euckr이 있다.

• <lang specific>: 지역/언어를 나타내며, en, de, es, fr, it, ja, km, ko, tr, vi, zh가 있다. 특정 언어를 나타내지 않을 때는 "gen"으로 일반적인 정렬 규칙을 의미한다.

• <desc1>_<desc2>_...: 대부분 LDML 콜레이션에만 적용되며 각각 다음의 의미를 갖는다.

  • ci: 대소문자 구분 안 함. LDML 파일에서 다음을 설정하면 적용된다: strength="secondary" caseLevel="off" caseFirst="off"

  • cs: 대소문자 구분. 기본적으로 모든 콜레이션은 대소문자를 구분한다. LDML 파일에서 다음을 설정하면 적용된다: strength="tertiary"

  • bin/binary: 정렬 순서가 코드포인트의 순서와 똑같음. 메모리의 바이트 순서를 비교하면 거의 같은 결과가 나오는데, 공백 문자와 EUC의 더블 바이트 패딩 문자는 "bin" 콜레이션에서 항상 0으로 정렬된다. LDML 파일에는 bin 콜레이션을 설정하는 방법이 없는데(bin 콜레이션은 이미 내장되어 있음), LDML 파일에서 다음을 설정하면 비슷하게 적용된다: strength="quaternary" 또는 strength="identical"

  • ai: 악센트 구분 안 함. 예를 들어, 'Á'는 'A'와 같은 순서이다. 이는 또한 대소문자를 구분하지 않는다. LDML 파일에서 다음을 설정하면 적용됨: strength="primary"

  • uca: UCA(Unicode Collation Algorithm) 기반 콜레이션을 의미함. 내장된 변형 콜레이션과 구별하기 위해서만 사용된다. 즉, 모든 LDML 콜레이션은 UCA를 기반으로 하지만 짧은 이름을 유지하기 위해 "_uca"가 생략되며, 예외적으로 'utf8_ko_cs_uca', 'utf8_tr_cs_uca' 이 두 개의 콜레이션만 내장된 'utf8_ko_cs', 'utf8_tr_cs' 콜레이션과 구별하기 위해 사용된다.

  • exp: 다른 콜레이션들이 문자 단위로 비교하는 것에 반해, 확장 은 전체 단어 매칭/비교 알고리즘을 사용한다. 이 콜레이션은 좀더 복잡한 알고리즘을 사용하므로 훨씬 느릴 수 있지만, 알파벳 정렬에 유용할 수 있다. LDML 파일에 다음이 명시되어야 한다: CUBRIDExpansions="use"

  • ab: 역순 액센트(accent backwards). 특히 캐나다 프랑스어에만 적용되는데, UCA 2단계(액센트 가중치를 저장)는 문자열의 끝에서부터 시작 방향으로 비교된다. 이 콜레이션 설정은 오직 확장 이 활성화되는 경우에만 사용될 수 있다. "ab" 설정은 다음 정렬을 허용한다:

    • 일반적인 액센트 순서: cote < coté < côte < côté
    • 역방향 액센트 순서: cote < côte < coté < côté

  • cbm: 축약 영역 매칭(contraction boundary match). 확장 과 축약 이 있는 콜레이션의 특별한 콜레이션이며, 매칭되는 문자열에서 축약 이 발견될 때 동작하는 방법을 설정한다.

    콜레이션의 축약 을 "ch"로 정의했다고 가정하자. 그러면 일반적으로 "bac"라는 패턴은 문자열 "bachxxx"와는 매칭되지 않는다. 그러나 콜레이션이 "축약을 시작하는 문자 매칭"을 허용하도록 설정되면, 앞서 말한 문자열들은 매칭된다. 이러한 식으로 동작하는 콜레이션은 'utf8_ja_exp_cbm' 밖에 없는데, 일본어 정렬은 무수히 많은 축약 을 요구한다.

콜레이션 이름은 동적으로 생성되지 않는다. LDML에 정의되어 있으며, 콜레이션 설정을 반영해야 한다. 콜레이션 이름은 콜레이션의 내부적인 ID에 영향을 준다. CUBRID는 256 개의 콜레이션을 허용하며, 각 식별자들은 다음과 같이 등록된다.

• 0 - 31: 내장된(built-in) 콜레이션(이름과 식별자가 제품에 포함됨)
• 32 - 46: 언어 부분에 "gen"을 가지는 LDML 콜레이션
• 47 - 255: 나머지 LDML 콜레이션

CUBRID가 제공하는 모든 로캘을 데이터베이스에 포함하고 싶다면, 먼저 $CUBRID/conf 디렉터리의 cubrid_locales.all.txt 파일을 cubrid_locales.txt 파일로 복사한다. 그리고, make_locale 스크립트(확장자가 Linux는 .sh, Windows는 .bat)를 실행하면 된다. make_locale 스크립트에 대한 자세한 설명은 2단계: 로캘 컴파일하기 를 참고하면 된다. 기존의 데이터베이스에 새로 추가한 로캘 정보를 포함하고 싶다면 cubrid synccolldb <dbname>을 실행한다. 이에 대한 자세한 설명은 데이터베이스 콜레이션을 시스템 콜레이션에 동기화 를 참고하면 된다.

LDML 파일로 정의된 로캘을 모두 포함하는 경우 CUBRID는 다음의 콜레이션을 가진다.

위에서 iso88591_bin, iso88591_en_cs, iso88591_en_ci, utf8_bin, euckr_bin, utf8_en_cs, utf8_en_ci, utf8_tr_cs, utf8_ko_cs와 같은 9 개의 콜레이션은 CUBRID에 기본적으로 내장되어 있다.

로캘 저장 위치¶

CUBRID는 로캘 설정을 위해 여러 디렉터리와 파일들을 사용한다.

• $CUBRID/conf/cubrid_locales.txt 파일: 사용할 로캘 리스트를 포함하는 초기 설정 파일
• $CUBRID/conf/cubrid_locales.all.txt 파일: cubrid_locales.txt 와 같은 구조를 갖는 초기 설정 파일의 템플릿. 사용자가 직접 정의하지 않아도 되는 CUBRID가 현재 지원하는 CUBRID 로캘 버전의 전체 리스트를 포함한다.
• $CUBRID/locales/data 디렉터리: 로캘 데이터를 생성하는데 필요한 파일들을 포함한다.
• $CUBRID/locales/loclib 디렉터리: 로캘 데이터를 포함하는 공유 라이브러리 생성을 위한 C 언어로 작성된 locale_lib_common.h 헤더 파일과 빌드를 위한 makefile을 포함한다.
• $CUBRID/locales/data/ducet.txt 파일: 코드포인트, 축약과 확장 등과 같은 기본적인 범용 콜레이션 정보와 이들의 가중치 값을 표현하는 파일로, 이 정보들은 유니코드 콘소시엄에 의해 제정된 표준을 따른다. 자세한 사항은 http://unicode.org/reports/tr10/#Default_Unicode_Collation_Element_Table 을 참고한다.
• $CUBRID/locales/data/unicodedata.txt 파일: 대소문자 구별, 분해, 정규화 등 각각의 유니코드 코드 포인트를 포함하는 파일로, CUBRID는 대소문자 구분 규칙을 결정하기 위해 이 파일을 사용한다. 더 많은 정보는 http://www.ksu.ru/eng/departments/ktk/test/perl/lib/unicode/UCDFF301.html 을 참고한다.
• $CUBRID/locales/data/ldml 디렉터리: cubrid_<locale_name>.xml 형식의 이름을 지니는 XML 파일들을 포함한다. 각각의 XML 파일은 해당 언어에 대한 로캘 정보를 표현한다.
• $CUBRID/locales/data/codepages 디렉터리: 한 바이트 코드 페이지들을 위한 코드 페이지 콘솔 변환용 파일들(8859-1.txt, 8859-15.txt, 8859-9.txt)과 멀티 바이트 코드 페이지를 위한 코드 페이지 콘솔 변환용 파일들(CP1258.txt, CP923.txt, CP936.txt, CP949.txt)을 포함한다.
• $CUBRID/bin/make_locale.sh 파일 또는 %CUBRID%\bin\make_locale.bat 파일(Windows): 로캘 데이터를 표현하는 공유 라이브러리를 생성하기 위해 사용되는 스크립트 파일이다.
• $CUBRID/lib 디렉터리: 로캘 데이터를 표현하는 공유 라이브러리 파일이 저장된다.

1단계: 로캘 선택¶

사용하려는 로캘을 $CUBRID/conf/cubrid_locales.txt 에 지정한다. 모두 선택하거나 부분만 선택할 수 있다.

CUBRID가 현재 지원하는 로캘은 en_US, de_DE, es_ES, fr_FR, it_IT, ja_JP, km_KH, ko_KR, tr_TR, vi_VN, zh_CN이며, 이 목록은 $CUBRID/conf/cubrid_locales.all.txt 에 작성되어 있다.

각 로캘 이름 및 언어, 사용 국가는 다음 표와 같다.

<lang_name>  <LDML file>                                        <lib file>
ko_KR        /home/CUBRID/locales/data/ldml/cubrid_ko_KR.xml    /home/CUBRID/lib/libcubrid_ko_KR.so

2단계: 로캘 컴파일하기¶

1단계에서 설명한 요구사항들이 충족되었다면 로캘 데이터를 컴파일할 수 있다.

CUBRID에 내장된 로캘을 사용한다면 사용자 로캘 라이브러리를 컴파일하지 않고 사용할 수 있으므로 2단계를 생략할 수 있으나, 내장된 로캘과 라이브러리 로캘에는 차이가 있다. 이와 관련하여 내장된 로캘과 라이브러리 로캘 을 참고한다.

로캘 데이터를 컴파일하려면 make_locale 스크립트(파일의 확장자는 Linux에선 .sh, Windows에선 .bat)를 사용한다. 이 스크립트는 $CUBRID/bin 디렉터리에 위치하며, 이 경로가 $PATH 환경 변수에 포함되어야 한다. 여기서 $CUBRID, $PATH 는 Linux의 환경 변수이며, Windows에서는 %CUBRID%, %PATH% 이다.

사용법은 make_locale.sh -h (Windows는 make_locale /h 이며, Visual C++ 2005, 2008 또는 2010 중 하나가 설치되어 있어야 한다.) 명령을 실행하면 출력되며, 사용 구문은 다음과 같다.

make_locale.sh [options] [locale]

options ::= [-t 32 | 64 ] [-m debug | release]
locale ::= [de_DE | es_ES | fr_FR | it_IT | ja_JP | km_KH | ko_KR | tr_TR | vi_VN | zh_CN]

• options
  • -t : 32비트 또는 64비트 중 하나를 선택한다(기본값: 32).
  • -m : release 또는 debug 중 하나를 선택한다. 일반적인 사용을 위해서는 release를 선택한다(기본값 : release). debug 모드는 로캘 라이브러리를 직접 작성하려는 개발자를 위해 제공한다.
• locale : 빌드할 라이브러리의 로캘 이름. locale 이 주어지지 않으면, 설정한 모든 로캘의 데이터를 포함하도록 빌드된다. 이 경우 $CUBRID/lib 디렉터리에 libcubrid_all_locales.so (Windows의 경우 .dll)라는 이름으로 라이브러리 파일이 저장된다.

여러 로캘에 대해서 사용자 정의 로캘 공유 라이브러리를 만들려면 다음 두 가지 방법 중 하나를 사용할 수 있다.

• 모든 로캘을 포함하는 하나의 라이브러리 생성: 다음과 같이 옵션을 지정하지 않고 실행한다.

  make_locale.sh                         # Build and pack all locales (32/release)
  

• 하나의 로캘만을 포함하는 라이브러리를 여러 개 반복하여 생성: 다음과 같이 하나의 언어를 지정한다.

  make_locale.sh -t 64 -m release ko_KR
  

이와 같은 두 가지 방법 중에서 첫 번째 방법을 사용하는 것을 권장한다. 공유 라이브러리를 생성하면 로캘들 간에 공유될 수 있는 데이터들이 중복되지 않기 때문에 메모리 사용량을 줄일 수 있다. 첫 번째 방식으로 지원하는 모든 로캘을 포함하도록 생성하면 약 15MB 정도 크기의 라이브러리가 생성되며, 두 번째 방식으로 생성할 경우에는 언어에 따라서 1MB에서 5MB 이상의 크기의 라이브러리가 생성된다. 또한 첫 번째 방식에서는 두 번째 방식을 사용했을 때에 서버 재시작 시점 등에 발생되는 런타임 오버헤드가 없기 때문에 런타임에도 유리하다.

3단계: 특정 로캘을 사용하기 위해 CUBRID 설정하기¶

여러 로캘을 정의할 수 있지만, CUBRID_CHARSET 환경 변수를 통해 오직 하나의 로캘을 기본 로캘로 지정할 수 있다. 언어에 따른 기본 캘린더(요일, 월, 오전/오후 표기 형식) 설정은 intl_date_lang 시스템 파라미터로 설정할 수 있다.

• CUBRID_CHARSET 환경 변수의 값은 <locale_name>[.utf8 | .iso88591]과 같이 설정한다. (예: tr_TR.utf8, en_US.iso88591, ko_KR.utf8)
• intl_date_lang 시스템 파라미터의 값은 <locale_name>과 같이 설정한다. <locale_name>으로 사용할 수 있는 값은 1단계: 로캘 선택 을 참고한다.

CUBRID_CHARSET 환경 변수는 제품 설치 초기에 en_US(문자셋은 ISO-8859-1)로 설정되어 있다.

4단계: 선택한 로캘 설정으로 데이터베이스 생성하기¶

CUBRID_CHARSET 환경 변수를 설정하면 새로운 데이터베이스를 생성할 수 있다. cubrid createdb <db_name>을 실행하면, 해당 언어와 문자셋을 사용하는 데이터베이스가 생성된다. 일단 데이터베이스가 생성되면 해당 데이터베이스에 부여된 로캘 설정은 바꿀 수 없다. 문자셋과 로캘 이름은 db_root 라는 시스템 카탈로그 테이블에 저장되며, 생성 시점의 설정과 다른 설정을 사용하여 데이터베이스를 구동할 수 없다.

5단계(선택 사항): 로캘 파일의 수동 검증¶

로캘 라이브러리의 내용들을 dumplocale 유틸리티를 이용해서 사람이 읽을 수 있는 형태로 출력할 수 있다. 사용법은 cubrid dumplocale -h 로 출력할 수 있다.

cubrid dumplocale [options] [language-string]

options ::= -i|--input-file <shared_lib>
            -d|--calendar
            -n|--numeric
            {-a |--alphabet=}{l|lower|u|upper|both}
            -c|--codepoint-order
            -w|--weight-order
            {-s|--start-value} <starting_codepoint>
            {-e|--end-value} <ending_codepoint>
            -k
            -z

language-string ::= de_DE | es_ES | fr_FR | it_IT | ja_JP | km_KH | ko_KR | tr_TR | vi_VN | zh_CN

• dumplocale: 로캘 라이브러리에 설정된 내용을 텍스트로 출력하는 명령이다.
• language-string: de_DE, es_ES, fr_FR, it_IT, ja_JP, km_KH, ko_KR, tr_TR, vi_VN, zh_CN 중 하나의 값. 로캘 공유 라이브러리를 덤프할 로캘 언어를 지정한다. language-string 이 생략되면 cubrid_locales.txt 파일에 명시된 모든 언어가 주어진다.

다음은 cubrid dumplocale 에 대한 [options]이다.

-i, --input-file=FILE¶

로캘 공유 라이브러리 파일 이름을 지정하며, 경로를 포함한다.

-d, --calendar¶

캘린더와 날짜/시간 정보를 추가로 덤프한다.

-n, --numeric¶

숫자 정보를 덤프한다.

-a, --alphabet=l | lower | u | upper | both¶

알파벳과 대소문자 구분 정보를 덤프한다.

--identifier-alphabet=l | lower | u | upper¶

식별자에 대한 알파벳과 대소문자 구분 정보를 추가로 덤프한다.

-c, --codepoint-order¶

코드포인트 값을 기반으로 정렬한 콜레이션 정보를 추가로 덤프한다. 출력되는 정보는 cp, char, weight, next-cp, char, weight이다.

-w, --weight-order¶

가중치 값을 기반으로 정렬한 콜레이션 정보를 추가로 덤프한다. 출력되는 정보는 weight, cp, char이다.

-s, --start-value=CODEPOINT¶

덤프 범위의 시작을 지정한다. -a , --identifier-alphabet , -c, -w 옵션들에 대한 시작 코드포인트이며, 기본값은 0이다.

-e, --end-value=CODEPOINT¶

덤프 범위의 끝을 지정한다. -a, --identifier-alphabet, -c, -w 옵션들에 대한 끝 코드포인트이며, 기본값은 로캘 공유 라이브러리에서 읽은 최대값이다.

-k, --console-conversion¶

콘솔 변환 데이터를 추가로 덤프한다.

-z, --normalization¶

정규화 데이터를 추가로 덤프한다.

다음은 캘린더 정보, 숫자 표기 정보, 알파벳 및 대소문자 정보, 식별자에 대한 알파벳 및 대소문자 정보, 코드포인트 순서에 기반한 콜레이션의 정렬, 가중치에 기반한 콜레이션의 정렬, 데이터를 정규화하여 ko_KR 로캘의 내용을 ko_KR_dump.txt라는 파일에 덤프하는 예이다.

% cubrid dumplocale -d -n -a both -c -w -z ko_KR > ko_KR_dump.txt

여러 개의 옵션을 설정하면 출력되는 내용이 매우 많을 수 있으므로, 파일로 리다이렉션하여 저장할 것을 권장한다.

6단계: CUBRID 관련 프로세스 시작¶

모든 CUBRID 관련 프로세스는 같은 환경 설정을 통해 구동되어야 한다. CUBRID 서버, 브로커, CAS, CSQL 등은 CUBRID_CHARSET 환경 변수의 설정값이 모두 같아야 하며, 같은 버전의 로캘 바이너리 파일을 사용해야 한다. CUBRID HA, CUBRID SHARD 구성 시에도 마찬가지이다. 예를 들어, CUBRID HA 구성에서 마스터 서버, 슬레이브 서버와 레플리카 서버 등은 환경 설정이 모두 같아야 한다.

서버 프로세스와 CAS 프로세스에 의해 사용되는 로캘의 호환성 여부를 시스템이 자동으로 검사하지 않기 때문에, 두 프로세스 간에 LDML 파일들이 똑같다는 것을 보장해야 한다.

로캘 라이브러리 로딩은 CUBRID 구동의 첫 단계로서, 구동 시에 데이터베이스 구조를 초기화하기 위해 로캘 정보를 요구하는 서버, CAS, CSQL, createdb, copydb, unloaddb, loaddb 프로세스 등은 구동 시점에 로캘 라이브러리를 로딩한다.

로캘 라이브러리 로딩 절차는 다음과 같다.

• 라이브러리 경로가 제공되지 않으면 $CUBRID/lib/libcubrid_<lang_name>.so 파일의 로딩을 시도한다. 이 파일이 발견되지 않으면 하나의 파일 $CUBRID/lib/libcubrid_all_locales.so 에서 모든 로캘이 발견된다고 간주한다.
• 로캘 라이브러리가 발견되지 않거나 라이브러리를 로딩하는 동안 오류가 발생하면 CUBRID 프로세스 구동이 종료된다.
• 데이터베이스와 로캘 라이브러리 간 콜레이션 정보가 다르면 CUBRID 프로세스가 구동되지 않는다. 기존 데이터베이스에 로캘 라이브러리의 변경된 콜레이션을 포함하려면, 먼저 cubrid synccolldb 명령을 수행하여 데이터베이스 콜레이션을 로캘 라이브러리에 맞게 동기화한다. 다음으로, 스키마와 데이터를 원하는 콜레이션에 맞게 기존 데이터베이스에 업데이트해야 한다. 자세한 내용은 데이터베이스 콜레이션을 시스템 콜레이션에 동기화 를 참고한다.

데이터베이스 콜레이션을 시스템 콜레이션에 동기화¶

CUBRID가 정상적으로 동작하기 위해서는 시스템 콜레이션과 데이터베이스 콜레이션이 같아야 한다. 시스템 로캘은 내장된 로캘과 cubrid_locales.txt 파일을 통해(로캘 설정 참고) 생성한 라이브러리 로캘을 포함한 로캘을 의미하며, 시스템 로캘은 시스템 콜레이션 정보를 포함한다. 데이터베이스 콜레이션 정보는 _db_collation 시스템 카탈로그 테이블에 저장된다.

cubrid synccolldb 유틸리티는 데이터베이스 콜레이션이 시스템 콜레이션과 일치하는지 확인하고, 다를 경우 데이터베이스 콜레이션을 시스템 콜레이션에 동기화하는 유틸리티이다. 하지만, 이 유틸리티는 데이터베이스 서버에 저장된 데이터 자체를 변환하지 않음을 인지해야 한다.

이 유틸리티는 시스템 로캘이 변경된 이후 기존의 데이터베이스 콜레이션 정보를 변경해야 할 때 사용할 수 있다. 단, 사용자가 직접 수동으로 진행해야 하는 작업들이 있다.

동기화 이전에 다음과 같은 작업을 수행한다. cubrid synccolldb -c 명령을 수행하여 생성되는 cubrid_synccolldb_<database_name>.sql 파일을 CSQL을 통해 실행하면 된다.

• ALTER TABLE MODIFY 문을 사용하여 콜레이션을 수정한다.
• 콜레이션을 포함하는 뷰, 인덱스, 트리거, 분할(partition) 등을 모두 제거한다.

cubrid synccolldb 를 가지고 동기화를 수행한다. 그리고 아래 작업을 수행한다.

• 뷰, 인덱스, 트리거, 분할 등을 재생성한다.
• 새로운 콜레이션에 맞게 응용 프로그램의 질의문들을 업데이트한다.

이 유틸리티는 데이터베이스를 정지한 상태에서 수행해야 한다.

synccolldb 구문은 다음과 같다.

cubrid synccolldb [options] database_name

• cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
• synccolldb: 데이터베이스 콜레이션을 시스템 콜레이션(로캘 라이브러리의 내용과 $CUBRID/conf/cubrid_locales.txt 파일을 따름)으로 동기화하는 명령이다.
• database_name: 콜레이션 정보가 로캘 라이브러리의 콜레이션에 맞게 동기화될 데이터베이스의 이름이다.

[options]를 생략하면 시스템과 데이터베이스 간 콜레이션 차이를 출력하고, 동기화 이전에 삭제되어야 할 객체 질의문을 포함하는 cubrid_synccolldb_<database_name>.sql 파일을 생성한다.

다음은 cubrid synccolldb 에서 사용하는 [options]이다.

-c, --check-only¶

데이터베이스의 콜레이션과 시스템의 콜레이션을 확인하여 불일치하는 콜레이션 정보를 출력한다.

-f, --force-only¶

데이터베이스에 있는 콜레이션 정보를 시스템에서 설정한 콜레이션과 동일하게 업데이트할 때 업데이트 여부를 질문하지 않는다.

다음의 예는 시스템 콜레이션과 데이터베이스의 콜레이션이 서로 다를 때 어떻게 동작하는지를 보여준다.

먼저 ko_KR 로캘에 대한 로캘 라이브러리를 생성한다.

$ echo ko_KR > $CUBRID/conf/cubrid_locales.txt
$ make_locale.sh -t 64

다음으로 데이터베이스를 생성한다.

$ cubrid createdb xdb --db-volume-size=20m --log-volume-size=20m

스키마를 생성한다. 이때, 각 테이블에 원하는 콜레이션을 지정한다.

$ csql -S -u dba xdb -i in.sql

CREATE TABLE dept (depname STRING PRIMARY KEY) COLLATE utf8_ko_cs_uca;
CREATE TABLE emp (eid INT PRIMARY KEY, depname STRING, address STRING) COLLATE utf8_ko_cs_uca;
ALTER TABLE emp ADD CONSTRAINT FOREIGN KEY (depname) REFERENCES dept(depname);

시스템의 로캘 설정을 변경한다. cubrid_locales.txt에 아무런 값도 설정하지 않으면 데이터베이스에는 내장된 로캘만 존재하는 것으로 간주한다.

$ echo "" > $CUBRID/conf/cubrid_locales.txt

cubrid synccolldb -c 명령을 수행하여 시스템과 데이터베이스 간 콜레이션 차이를 확인한다.

$ cubrid synccolldb -c xdb

----------------------------------------
----------------------------------------
Collation 'utf8_ko_cs_uca' (Id: 133) not found in database or changed in new system configuration.
----------------------------------------
----------------------------------------
Collation 'utf8_gen_ci' (Id: 44) not found in database or changed in new system configuration.
----------------------------------------
----------------------------------------
Collation 'utf8_gen_ai_ci' (Id: 37) not found in database or changed in new system configuration.
----------------------------------------
----------------------------------------
Collation 'utf8_gen' (Id: 32) not found in database or changed in new system configuration.
----------------------------------------
----------------------------------------
There are 4 collations in database which are not configured or are changed compared to system collations.
Synchronization of system collation into database is required.
Run 'cubrid synccolldb -f xdb'

인덱스가 존재한다면 먼저 인덱스를 제거한 후 각 테이블의 콜레이션을 변환하고, 이후 인덱스 생성을 직접 수행해야 한다. 인덱스를 제거하고 테이블의 콜레이션을 변환하는 과정은 synccolldb에서 생성된 cubrid_synccolldb_xdb.sql 파일로 수행할 수 있다. 다음 예에서는 외래 키가 재생성해야 될 인덱스에 해당한다.

$ cat cubrid_synccolldb_xdb.sql

ALTER TABLE [dept] COLLATE utf8_bin;
ALTER TABLE [emp] COLLATE utf8_bin;
ALTER TABLE [emp] DROP FOREIGN KEY [fk_emp_depname];
ALTER TABLE [dept] MODIFY [depname] VARCHAR(1073741823) COLLATE utf8_bin;
ALTER TABLE [emp] MODIFY [address] VARCHAR(1073741823) COLLATE utf8_bin;
ALTER TABLE [emp] MODIFY [depname] VARCHAR(1073741823) COLLATE utf8_bin;

$ csql -S -u dba -i cubrid_synccolldb_xdb.sql xdb

시스템 콜레이션을 데이터베이스에 동기화하기 전에 위의 cubrid_synccolldb_xdb.sql 스크립트 파일을 실행하여 예전의 콜레이션들을 삭제해야 한다.

cubrid synccolldb 명령을 수행한다. 옵션을 생략하면 해당 명령을 수행할 것인지를 확인하는 메시지가 나타나며, -f 옵션을 주면 확인 과정 없이 데이터베이스와 시스템 간 콜레이션 동기화를 수행한다.

$ cubrid synccolldb xdb
Updating system collations may cause corruption of database. Continue (y/n) ?
Contents of '_db_collation' system table was updated with new system collations.

DROP된 외래 키를 다시 생성한다.

$ csql -S -u dba xdb

ALTER TABLE emp ADD CONSTRAINT FOREIGN KEY fk_emp_depname(depname) references dept(depname);

칼럼의 문자셋과 콜레이션¶

칼럼의 문자셋과 콜레이션은 문자열 데이터 타입(VARCHAR, CHAR)과 ENUM 타입에 적용된다. 기본적으로 모든 문자열 데이터 타입은 데이터베이스의 기본 문자셋과 콜레이션을 따르는데, 이를 변경하여 지정할 수 있는 방법을 제공한다.

coll_id  coll_name        charset_name    is_builtin  has_expansions  contractions  uca_strength
================================================================================================
0        'iso88591_bin'   'iso88591'     'Yes'        'No'            0             'Not applicable'
1        'utf8_bin'       'utf8'         'Yes'        'No'            0             'Not applicable'
2        'iso88591_en_cs' 'iso88591'     'Yes'        'No'            0             'Not applicable'
3        'iso88591_en_ci' 'iso88591'     'Yes'        'No'            0             'Not applicable'
4        'utf8_en_cs'     'utf8'         'Yes'        'No'            0             'Not applicable'
5        'utf8_en_ci'     'utf8'         'Yes'        'No'            0             'Not applicable'
6        'utf8_tr_cs'     'utf8'         'Yes'        'No'            0             'Not applicable'
7        'utf8_ko_cs'     'utf8'         'Yes'        'No'            0             'Not applicable'
8        'euckr_bin'      'euckr'        'Yes'        'No'            0             'Not applicable'

<data_type> ::= <column_type> [<charset_modifier_clause>] [<collation_modifier_clause>]

<charset_modifier_clause> ::= {CHARACTER_SET | CHARSET} {<char_string_literal> | <identifier> }

<collation_modifier_clause> ::= COLLATE {<char_string_literal> | <identifier> }

CREATE TABLE t1 (s1 VARCHAR (100) CHARSET utf8);

ALTER TABLE t1 CHANGE s1 c1 CHAR(10) COLLATE utf8_en_cs;

SELECT CAST (c1 as VARCHAR(5) COLLATE 'iso88591_en_ci') FROM t1 ORDER BY 1;

SELECT c1 FROM t1 ORDER BY CAST (c1 as VARCHAR(5) COLLATE iso88591_en_ci);

CREATE TABLE t (s1 STRING COLLATE utf8_en_cs, s2 STRING COLLATE utf8_tr_cs);

-- insert values into both columns

SELECT s1, s2 FROM t WHERE s1 > s2;

테이블의 문자셋과 콜레이션¶

테이블 생성 구문에 문자셋과 콜레이션을 지정할 수 있다.

CREATE TABLE table_name ( column_list ) [CHARSET charset_name] [COLLATE collation_name]

칼럼의 문자셋과 콜레이션이 생략되면, 테이블의 문자셋과 콜레이션이 사용된다. 테이블의 문자셋과 콜레이션이 생략되면, 시스템의 문자셋과 콜레이션이 사용된다.

다음은 테이블에 콜레이션을 지정하는 예이다.

CREATE TABLE tbl (i1 INTEGER, s STRING) CHARSET utf8 COLLATE utf8_en_cs;

문자열 리터럴의 문자셋과 콜레이션¶

문자열 리터럴(string literal)의 문자셋과 콜레이션은 다음과 같은 우선 순위에 따라 정해진다.

1. 문자셋 소개자 또는 문자열의 COLLATE 수정자
2. SET NAMES 문으로 명시한 문자셋과 콜레이션
3. 시스템 문자셋과 콜레이션(문자셋과 CUBRID_CHARSET 환경 변수에 의해 설정된 기본 콜레이션)

SET NAMES [charset_name] [COLLATE collation_name]

SELECT 'a';

SET NAMES utf8;
SELECT 'a';

[charset_introducer]'constant-string' [COLLATE collation_name]

SELECT 'cubrid';
SELECT _utf8'cubrid';
SELECT _utf8'cubrid' COLLATE utf8_en_cs;

SET NAMES utf8 COLLATE utf8_en_ci;
SELECT 'a' COLLATE utf8_en_cs;

표현식의 문자셋과 콜레이션¶

표현식 결과의 문자셋과 콜레이션은 표현식의 인자들로부터 추론된다. 콜레이션 추론 과정은 콜레이션 변환도(coercibility)에 기반하며 이에 관한 자세한 내용은 콜레이션이 서로 다를 때 결정 방식을 참고한다.

모든 문자열 매칭 함수(LIKE, REPLACE, INSTR, POSITION, LOCATE, SUBSTRING_INDEX, FIND_IN_SET 등)와 비교 연산자들(<, >, = 등)에서 콜레이션이 고려된다.

시스템 데이터의 문자셋과 콜레이션¶

시스템 문자셋은 CUBRID_CHARSET 환경 변수에서 가져온다. 시스템의 콜레이션은 항상 시스템 문자셋의 바이너리 콜레이션(<charset>_bin)이다. CUBRID는 iso88591, euckr, utf8 3 개의 문자셋을 지원하며, 따라서 기본적으로 3 개의 시스템 콜레이션을 지원한다.

CUBRID_CHARSET의 영향¶

CUBRID_CHARSET의 로캘 부분은 다음에 영향을 끼친다.

• 식별자(identifier)와 대소문자 규칙에서 지원되는 문자(이를 "알파벳"이라고 지칭함)
• 날짜-문자열 변환 함수들에 대한 기본 로캘
• 숫자-문자열 변환 함수들에 대한 기본 로캘
• CSQL에서 콘솔 변환

CREATE TABLE ÈABC;

문자열 리터럴의 입출력¶

문자열 리터럴 데이터는 CUBRID에 다양한 방법으로 입력된다.

• C API interface (CCI)
• 언어 의존적인 인터페이스. JDBC, Perl 드라이버 등
• CSQL - 콘솔 또는 파일로부터 입력

드라이버를 통해 문자 데이터를 받을 때, CUBRID는 이 문자들의 문자셋을 인지할 수 없다. 문자열 리터럴(따옴표로 감싼 문자)에 해당하는 모든 텍스트 데이터는 있는 그대로(raw data) 다루어진다. 문자셋 메타 정보는 응용 클라이언트에 의해 제공되어야 한다. 클라이언트는 SET NAMES 문 이나 문자셋 소개자 를 통해 문자셋 정보를 제공할 수 있다.

<consoleconversion type="ISO88599" windows_codepage="28599" linux_charset="iso88599,ISO_8859-9,ISO8859-9,ISO-8859-9" />

콜레이션의 축약과 확장¶

콜레이션의 구축을 위해 축약(contraction)과 확장(expansion)을 지원하며, 축약과 확장은 UTF-8 문자셋 콜레이션에서만 가능하다. 이러한 축약과 확장은 LDML 파일의 콜레이션 설정에서 정의할 수 있는데, 이들의 사용은 로캘 데이터(공유 라이브러리)의 크기와 서버의 성능 모두에 영향을 준다.

문자셋과 콜레이션을 필요로 하는 연산¶

문자셋

문자셋 정보는 문자열 데이터를 사용하는 연산자와 함수들에게 필요한 정보이다. 하지만 예외적으로, OCTET_LENGTH() 함수와 BIT_LENGTH() 함수는 바이트와 비트 값을 반환하기 위해 문자셋 정보가 불필요하다. 그러나, 다른 문자셋으로 저장된 같은 글리프(glyph, 문자 기호)에 대해 이 함수들을 수행하면 다른 값을 반환한다.

CREATE TABLE t (s_iso STRING CHARSET iso88591, s_utf8 STRING CHARSET utf8);
SET NAMES iso88591;
INSERT INTO t VALUES ('È','È');

-- the first returnes 1, while the second does 2
SELECT OCTET_LENGTH (s_iso), OCTET_LENGTH (s_utf8) FROM t;

위의 예는 콘솔(또는 응용 클라이언트)에서 iso88591 문자셋으로 질의를 입력해야 한다.

콜레이션

콜레이션은 STRCMP(), POSITION(), LIKE 조건, <, =, > 등 두 문자열 간의 비교 또는 매칭을 수반하는 연산자와 함수에서 필요하다. 또한 ORDER BY, GROUP BY 및 집계 함수(MIN(), MAX(), GROUP_CONCAT()) 등에서도 콜레이션이 필요하다.

콜레이션은 또한 UPPER(), LOWER() 함수에서도 고려되는데, 다음과 같이 동작한다.

• 각 콜레이션은 부모에 해당하는 기본 로캘이 있다.
• UPPER와 LOWER 함수는 콜레이션의 기본 로캘을 사용하여 수행된다.

대부분의 콜레이션에서 기본 로캘은 명확하다(콜레이션 이름에 포함됨).

• utf8_tr_cs → tr_TR.utf8
• iso88591_en_ci → en_US (ISO-8859-1 문자셋)

바이너리 콜레이션은 다음의 기본 로캘을 가지고 있다.

• iso88591_bin → en_US (ISO-8859-1 문자셋)
• utf8_bin (en_US.utf8 - 내장된 로캘 - ASCII 문자만 다룬다)
• euckr_bin (ko_KR.euckr - 내장된 로캘 - ASCII 문자만 다룬다)

LDML에서 정의한 일반적인(generic) 콜레이션들이 있는데, 이 콜레이션들은 $CUBRID/conf/cubrid_locales.txt 파일에서 먼저 나타나는 로캘을 기본 로캘로 가진다. 최초 설치 시 가장 처음에 나타나는 로캘은 de_DE(독일어)이므로, de_DE가 일반적인 콜레이션의 기본 로캘이 된다.

문자셋 변환

CUBRID가 지원하는 3 가지 문자셋에 대한 변환 규칙은 다음과 같다.

• euckr과 utf8 간의 상호 변환은 허용되지 않는다.

• iso88591에서 utf8로의 변환 - 바이트 변환

• iso88591에서 euckr로 변환 - 허용되지 않는다. (일부 문자가 EUC-KR로 인코딩될 수 없음)

• utf8과 euckr에서 iso88591로 변환 - 바이트 재해석; 변환될 값이 무제한의 자릿수(precision)를 가지는 타입이면, 저장 공간의 크기는 같지만 자릿수는 증가한다.

  Note

  문자셋 변환 시 9.0 버전에서 어떤 값이 정해진 자릿수를 지닌 타입이면 자릿수는 유지되고 데이터가 절삭되었다. 9.1 버전부터는 자릿수를 확장하고 데이터를 유지한다.

콜레이션 설정으로 인한 영향¶

LIKE 조건 최적화

LIKE 조건은 문자열 데이터 간의 패턴을 비교하여 문자열이 패턴과 매칭되면 TRUE 를 리턴한다. 확장이 없는 콜레이션을 사용할 때에는 각 코드포인트는 가중치를 나타내는 하나의 정수 값을 갖는데, 이 가중치 값은 콜레이션 설정(세기, 대소문자 구분 등)에 기반하여 계산된다.

문자들은 항상 하나의 개체(entity)로 간주될 수 있기 때문에, LIKE 조건을 사용한 패턴으로 문자열을 매칭하려는 시도는 문자열이 어떤 범위 내에서 발견될 수 있는지 확인하는 것과 같다고 볼 수 있다. 예를 들어, "s LIKE 'abc%'"는 칼럼 s의 값은 문자열 "abc"로 시작해야 한다는 것을 의미하므로, "s LIKE 'abc%'"와 같은 절을 수행하기 위해 먼저 칼럼 s의 문자열에 대한 제한 범위로 구문을 재작성한다. 확장이 없는 콜레이션에서 이는 s가 "abc"보다 크거나 같지만 뒤따르는 문자열보다 작다는 의미이다. 예를 들어, 영어의 알파벳 기준으로 'abc'에 뒤따르는 문자열은 'abd'이므로 아래와 같이 변환할 수 있다.

s LIKE 'abc%' → s ≥ 'abc' AND s < 'abd' (if using strictly the English aphabet)

이와 같이 LIKE 조건의 패턴은 간단한 비교 조건으로 대체될 수 있는데, 확장이 있는 콜레이션의 경우는 다르게 동작한다. 확장이 있는 콜레이션을 사용할 때 문자열을 비교하는 것은 각 코드포인트나 확장에 대해 각 수준(level)별로 콜레이션 원소의 결합된 리스트들을 비교하는 것을 뜻한다. 확장이 있는 콜레이션에서 문자열 비교에 대한 자세한 내용은 확장 을 참고하면 된다.

확장이 있는 콜레이션에 대해서 위의 예와 같이 LIKE 조건을 일반 비교 조건으로 변환하면 비교가 잘못될 수 있다. 정확한 질의 결과를 보장하기 위하여 확장이 있는 콜레이션의 경우에는 LIKE 조건 재작성 방법이 아래의 예와 같이 다르게 동작한다. 즉, 범위 조건으로 변경하고 확장 있는 콜레이션에서 잘못 추가될 수 있는 데이터들을 배제시키기 위해 주어진 LIKE 조건이 필터로 추가된다.

s LIKE 'abc%' → s ≥ 'abc' AND s < 'abd' and s LIKE 'abc%' (if using strictly the English aphabet)

prefix 인덱스와 콜레이션 확장

확장이 있는 콜레이션을 가진 칼럼에는 prefix 인덱스를 생성할 수 없다.

CREATE TABLE t1 (s1 VARCHAR (200) COLLATE utf8_ja_exp);
CREATE INDEX idx_t_s1 on t (s1 (5));

ERROR: before ' ; '
Prefix index is not allowed on attribute 's' (has collation with expansions).

커버링 인덱스

커버링 인덱스 스캔은 실제 레코드를 액세스하지 않고 인덱스에 있는 값만을 사용해서 질의를 처리하는 질의 최적화 기법으로, 이에 대한 자세한 내용은 커버링 인덱스 를 참고한다.

대소문자 구분이 없는 콜레이션에서 'abc'와 'ABC' 두 개의 문자열을 인덱스에 저장한다고 가정할 때 인덱스의 키 값으로 이 중 하나만이 저장된다. 이와 같이 하나의 콜레이션에서 서로 다른 두 개 이상의 문자열이 하나의 키 값을 가지게 되면, 정확한 질의 결과를 만들어낼 수 없게 된다. 결국 수준 4(quarternary) 보다 작은 세기(strength)의 모든 UTF-8 콜레이션에서 커버링 인덱스에 의한 질의 최적화는 적용되지 않는다.

이러한 세기 수준은 LDML에서 콜레이션 정의를 위한 <strength> 태그의 strength="tertiary/quarternary"에 의해 제어될 수 있다. 확장이 있는 콜레이션의 세기 값을 최대 값으로 설정하는 것은 주의깊게 고려되어야 하는데, 네 번째 세기 수준은 공유 라이브러리 크기와 메모리 요구량이 커질 뿐만 아니라 문자열 비교 시간을 증가시키기 때문이다.

콜레이션과 관련된 자세한 내용은 콜레이션 설정을 참고한다.

각 콜레이션에 대한 기능 요약

콜레이션	LIKE 문을 범위로 재작성 이후 조건 유지	커버링 인덱스 허용	prefix 인덱스 허용
iso88591_bin	No	Yes	Yes
iso88591_en_cs	No	Yes	Yes
iso88591_en_ci	Yes	No	Yes
utf8_bin	No	Yes	Yes
euckr_bin	No	Yes	Yes
utf8_en_cs	No	Yes	Yes
utf8_en_ci	Yes	No	Yes
utf8_tr_cs	No	Yes	Yes
utf8_ko_cs	No	Yes	Yes
utf8_gen	No	Yes	Yes
utf8_gen_ai_ci	Yes	No	Yes
utf8_gen_ci	Yes	No	Yes
utf8_de_exp_ai_ci	Yes	No	No
utf8_de_exp	Yes	No	No
utf8_es_cs	No	Yes	Yes
utf8_fr_exp_ab	Yes	No	No
utf8_ja_exp	Yes	No	No
utf8_ja_exp_cbm	Yes	No	No
utf8_km_exp	Yes	No	No
utf8_ko_cs_uca	No	Yes	Yes
utf8_tr_cs_uca	No	Yes	Yes
utf8_vi_cs	No	Yes	Yes

콜레이션 정보 보기¶

콜레이션 정보를 보려면 CHARSET(), COLLATION() 및 COERCIBILITY() 정보 함수를 사용한다.

데이터베이스 콜레이션 정보는 db_collation 시스템 뷰 또는 SHOW COLLATION을 통해 확인할 수 있다.

CUBRID_CHARSET¶

• 기본적으로 CUBRID_CHARSET=en_US를 사용한다. 이 설정이 가장 좋은 성능을 낸다.
• UTF-8 로캘의 사용은 CHAR 타입에 대해 추가적인 저장 공간을 필요로 한다. 고정 길이 문자 타입(CHAR)의 경우 4배까지 늘어나며, EUC-KR의 경우 3배까지 늘어난다.
• 사용자 문자열 리터럴이 시스템과 다른 문자셋과 콜레이션을 가진다면, 질의문은 문자셋과 콜레이션을 설정하기 위해 더 길어질 것이다.
• ASCII 문자가 아닌 문자를 사용자 식별자로 사용하려면 .utf8 로캘을 사용한다.
• UTF-8 문자셋으로 CUBRID_CHARSET을 설정하면, LDML 로캘을 사용하는 것이 좋다. LDML 로캘이 식별자에 포함된 유니코드 문자의 대소문자 변환을 보장한다.
• 로캘 설정은 문자열 변환 함수에도 영향을 준다. 가장 빈번하게 변환이 이루어지는 로캘을 선택하는 것이 좋다.
• CUBRID_CHARSET 설정 시 문자열 상수, 사용자 테이블 칼럼의 문자셋과 콜레이션에 대해 고민하지 않아도 된다. 질의문에서 CAST() 연산자를 사용하여 런타임에 바꿀 수 있으며, "ALTER ... CHANGE" 문을 통해 영구히 바꿀 수 있다.

CHAR와 VARCHAR¶

• 일반적으로 데이터의 크기 변화가 심할 때는 VARCHAR를 사용한다.
• CHAR 타입은 고정 길이 타입이므로, 영문만 저장하는 경우에도 UTF-8은 4 bytes의 저장 공간을, EUC-KR은 3 bytes의 저장 공간을 필요로 한다.
• 칼럼의 자릿수(precision)는 문자(글리프, 문자 기호)의 개수이다.
• 자릿수를 정한 이후에, 대부분의 사용 시나리오에 따라 문자셋과 콜레이션이 설정되어야 한다.

문자셋 선택¶

• 텍스트가 ASCII가 아닌 문자를 포함하고 있더라도 응용 프로그램이 문자 개수 세기, 문자열 치환 등의 문자열 조작이 필요한 경우에 utf8이나 euckr 문자셋을 사용한다.
• CHAR 타입의 저장 공간을 고려해야 한다.
• CHAR와 VARCHAR 타입에서 INSERT/UPDATE 시 오버헤드가 있다. 각 행에서 문자열의 문자 개수(precision)를 세는 것은 ISO가 아닌 문자셋에서 더 많은 수행 시간을 필요로 한다.
• 질의문 내의 표현식의 문자셋은 CAST() 연산자를 사용하여 변환할 수 있다.

콜레이션 선택¶

• 콜레이션 의존적인 동작(문자열 검색, 정렬, 비교, 대소문자화)이 수행되지 않는다면, 해당 문자셋의 바이너리 콜레이션을 사용한다.
• 표현식의 원래 문자셋과 새로운 콜레이션 사이에서 문자셋이 변경되지 않는다면 콜레이션은 CAST() 연산자, COLLATE 수정자를 사용하여 쉽게 오버라이드할 수 있다.
• 콜레이션은 문자열의 대소문자 구분 규칙을 제어한다.
• 확장이 있는 콜레이션은 더 느리지만 더 유연하며 전체 단어 정렬을 수행한다.

정규화¶

• 응용 클라이언트가 CUBRID에 분해된 형태의 텍스트 데이터를 보낸다면, unicode_input_normalization = yes로 설정하여 CUBRID가 재구성하여 결합된 형태로 다룰 수 있도록 한다.
• 응용 클라이언트가 분해된 형태만 다룰 수 있다면, unicode_output_normalization = yes로 설정하여 CUBRID가 항상 분해된 형식으로 텍스트 데이터를 보내도록 한다.
• 응용 클라이언트가 모든 형식을 알고 있다면, unicode_output_normalization = no인 상태로 둔다.

CAST vs COLLATE¶

• CAST() 연산자는 COLLATE 수정자 보다 더 많은 실행 비용이 든다.
• COLLATE 수정자 는 질의 실행 과정에서 실행 연산이 추가되지 않기 때문에, COLLATE 수정자 를 사용하는 것이 CAST() 연산자를 사용하는 것보다 실행 속도가 더 빠르다.
• COLLATE 수정자 는 문자셋이 바뀌지 않을 때만 사용될 수 있다.