CachéDBMSソートテーブル

しかし、なんということでしょう！

（A.S.プーシキン）



これがTwitterの投稿であれば、「 CachéObjectScriptプログラマー！ Cyrillic3の代わりにCyrillic4を使用してください！ 「。 しかし、ここで、Habr、それは思考を広げる必要がある-猫の下で歓迎。



Cachéのすべてはグローバルに保存されます。 データ、メタデータ、クラス、プログラム。 グローバルノードは添え字の値でソートされ、挿入された順序ではなく、クイック検索のためにソートされてディスクに保存されます。

USER>set ^a(10)="" USER>set ^a("")="" USER>set ^a("")="" USER>set ^a(2)="" USER>zwrite ^a ^a(2)="" ^a(10)="" ^a("")="" ^a("")=""
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

並べ替えるとき、Cachéは数字と文字列を区別します-2は数字と見なされ、10より前に並べ替えられます。zwriteコマンドと$ Orderおよび$ Query関数は、グローバルインデックスをディスクに格納されている順序で表示します。最初は空の文字列、次に負の数字、正の数、次に照合テーブルによって決定された順序の行。



最も単純な場合、ソートテーブルは各文字とシーケンス番号を照合します。 次に、並べ替えテーブルを並べ替えます。



Cachéの標準ソートは、Caché標準と呼ばれます。 各文字をUnicodeコードにマッピングします。



現在のプロセスでローカル配列が作成されるソートは、ロケール（管理ポータル>システム管理>構成>各国語のサポートの設定）によって決定されます。 ロシアのCachéUnicodeインストールのロシア語ロケールのruswの場合、既定の並べ替えテーブルはCyrillic3です。 ruswで可能なその他のソートは、Caché標準、Cyrillic1、Cyrillic3、Cyrillic4、Ukrainian1です。



##クラス（％Collat​​e）.SetLocalName（）メソッドは、現在のプロセスのローカル配列のソートを変更します。

 USER>write ##class(%Collate).GetLocalName() Cyrillic3 USER>write ##class(%Collate).SetLocalName("Cache standard") 1 USER>write ##class(%Collate).GetLocalName() Cache standard USER>write ##class(%Collate).SetLocalName("Cyrillic3") 1 USER>write ##class(%Collate).GetLocalName() Cyrillic3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各ソートには、数値が文字列としてソートされるペアがあります。 このようなペアソートの名前は、元のソートの名前に「string」を追加することによって取得されます。

 USER>write ##class(%Collate).SetLocalName("Cache standard string") 1 USER>kill test USER>set test(10) = "", test(2) = "", test("") = "", test("") = "" USER>zwrite test test(10)="" test(2)="" test("")="" test("")="" USER>write ##class(%Collate).SetLocalName("Cache standard") 1 USER>kill test USER>set test(10) = "", test(2) = "", test("") = "", test("") = "" USER>zwrite test test(2)="" test(10)="" test("")="" test("")=""
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Caché標準およびCyrillic3

Caché標準では、文字はUnicodeコードの順にソートされます。

  write ##class(%Library.Collate).SetLocalName("Cache standard"),! write ##class(%Library.Collate).GetLocalName(),! set letters = "" set letters = letters _ $zconvert(letters,"U") kill test // test  for i=1:1:$Length(letters) { set test($Extract(letters,i)) = "" } //   test    set l = "", cnt = 0 for { set l = $Order(test(l)) quit:l="" write l, " ", $Ascii(l),"," set cnt = cnt + 1 write:cnt#8=0 ! }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 USER>do ^testcol 1 Cache standard  1025, 1040, 1041, 1042, 1043, 1044, 1045, 1046,  1047, 1048, 1049, 1050, 1051, 1052, 1053, 1054,  1055, 1056, 1057, 1058, 1059, 1060, 1061, 1062,  1063, 1065, 1066, 1067, 1068, 1069, 1070, 1071,  1072, 1073, 1074, 1075, 1076, 1077, 1078, 1079,  1080, 1081, 1082, 1083, 1084, 1085, 1086, 1087,  1088, 1089, 1090, 1091, 1092, 1093, 1094, 1095,  1097, 1098, 1099, 1100, 1101, 1102, 1103, 1105,
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

文字およびexceptを除くすべての文字が配置されています。 Unicodeのコードは一般的な順序から外れています。 したがって、ロシア語ロケールの場合、独自の並べ替えテーブルCyrillic3が必要でした。Cyrillic3では、文字はロシア語のアルファベットと同じ順序になります。

 USER>do ^testcol 1 Cyrillic3  1040, 1041, 1042, 1043, 1044, 1045, 1025, 1046,  1047, 1048, 1049, 1050, 1051, 1052, 1053, 1054,  1055, 1056, 1057, 1058, 1059, 1060, 1061, 1062,  1063, 1065, 1066, 1067, 1068, 1069, 1070, 1071,  1072, 1073, 1074, 1075, 1076, 1077, 1105, 1078,  1079, 1080, 1081, 1082, 1083, 1084, 1085, 1086,  1087, 1088, 1089, 1090, 1091, 1092, 1093, 1094,  1095, 1097, 1098, 1099, 1100, 1101, 1102, 1103,
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CachéObjectScriptには、特別なバイナリ演算子]]]-「ソート後」があります。 配列インデックス内で左引数が右引数の後に配置される場合は1を返し、それ以外の場合は0を返します。

 USER>write ##class(%Library.Collate).SetLocalName("Cache standard"),! 1 USER>write "" ]] "" 1 USER>write ##class(%Library.Collate).SetLocalName("Cyrillic3"),! 1 USER>write "" ]] "" 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

グローバルとソートテーブル

同じデータベース内の異なるグローバルは、異なるソートを持つことができます。 各データベースには設定があります-新しいグローバルのソート。 インストール直後、 USERを除くすべてのデータベースの場合、新しいグローバルの既定の並べ替えはCaché標準です。 USERの場合、インストールロケールによって異なります。 ruswの場合 -キリル文字3。



このデータベースのデフォルトのソートとは異なるソートでグローバルを作成します。

 USER>kill ^a USER>write ##class(%GlobalEdit).Create(,"a",##class(%Collate).DisplayToLogical("Cache standard"))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

管理ポータルのグローバルのリスト（[システムブラウザー]> [グローバル]）には、各グローバルのソートが表示されます（4列目）。



既存のグローバルのソートを変更することはできません。 新しいソートでグローバルを作成し、mergeコマンドで古いグローバルからデータをコピーする必要があります。 ##クラス（SYS.Database）.Copy（）メソッドを使用して、ある種類から別の種類へのグローバルの一括変換を実行できます。

Cyrillic4、Cyrillic3、ウムラウト

Cyrillic3の操作中に、テキストインデックスから内部形式への変換にはCaché標準のソートよりも時間がかかるため、Cyrillic3ソートを使用したグローバル（またはローカル配列）の挿入とナビゲートが遅いことがわかりました。 バージョン2014.1から利用可能な新しいCyrillic4照合が作成されました。 その中のキリル文字の順序はキリル文字3と同じですが、キリル文字4は著しく高速です。

 for collation="Cyrillic3","Cyrillic4","Cache standard","Cyrillic1" { write ##class(%Library.Collate).SetLocalName(collation),! write ##class(%Library.Collate).GetLocalName(),! do test(100000) } quit test(C) set letters = "" set letters = letters _ $zconvert(letters,"U") kill test write "test insert: " //  test  set z1=$zh for c=1:1:C { for i=1:1:$Length(letters) { set test($Extract(letters,i)_"   " _ $Extract(letters,i)) = "" } } write $zh-z1,! //   test write "test $Order: " set z1=$zh for c=1:1:C { set l = "" for { set l = $Order(test(l)) quit:l="" } } write $zh-z1,!
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 USER>do ^testcol 1 Cache standard test insert: 1.520673 test $Order: 2.062228 1 Cyrillic3 test insert: 3.541697 test $Order: 5.938042 1 Cyrillic4 test insert: 1.925205 test $Order: 2.834399
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Cyrillic4はまだruswロケールのデフォルトの並べ替えではありませんが、ruswに基づいて独自のロケールを作成することにより、Cyrillic4をローカル配列のデフォルトの並べ替えとして指定できます。 または、データベース設定で新しいグローバルのデフォルト照合としてCyrillic4を指定します。



Cyrillic3は、Caché標準およびCyrillic4よりも低速です。これは、Cyrillic3は、これらの行の対応する文字のコードに応じて2行をソートするよりも一般的なアルゴリズムに基づいているためです。



ドイツ語では、並べ替えるとき、 文字ßはssとして解釈される必要があります 。 これは、Cachéでの動作です。

 USER>write ##class(%Collate).GetLocalName() German3 USER>set test("Straßer")=1 USER>set test("Strasser")=1 USER>set test("Straster")=1 USER>zwrite test test("Strasser")=1 test("Straßer")=1 test("Straster")=1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

行の順序に注意してください。 つまり、最初の行の最初の4文字が「Stras」、次に「Straß」、そして再び「Stras」であるということです。 各文字が何らかのコードに関連付けられている場合、この順序は実現できません。



ロシア語には幸運です-たとえばフィンランド語のvやwのように、同じ方法でソートできるウムラウトや文字はありません。 ロシア語では、各文字に番号を付け、対応する位置の文字番号に従って行を比較するだけで十分です。 このため、Cyrillic4で速度が向上することが判明しました。

並べ替えとSQLテーブル

グローバルの照合テーブルとSQLの列の照合（照合も）を混同しないでください。 2番目の並べ替えは、値をインデックスグローバルに配置するか、別の値と比較する前に値に適用される変換です。 CachéSQLでは、行の既定の照合はSQLUPPERです。 この変換は、すべての文字を大文字に変換し、末尾の空白を削除し、行の先頭にスペースを1つ追加します。 他の3つのSQLソート（ EXACT 、 SQLSTRING 、 TRUNCATE ）は、 ドキュメントに記載されています 。

ある程度のスキルがあれば、データベース内の異なるグローバルに異なる並べ替えがあり、ローカルアレイに3番目の並べ替えがある場合、混乱を引き起こすことは難しくありません。 内部的なニーズのために、SQLはCACHETEMPベースを使用します。グローバルの並べ替えは、現在のロケールのデフォルトの並べ替えとも異なる場合があります。



基本的なルールは1つです。したがって、SQLクエリのORDER BYは期待される順序で行を返すため、クエリに参加するテーブルのデータとインデックスが格納されるグローバルの並べ替えは、 CACHETEMPデータベースのデフォルトの並べ替えとローカル配列の並べ替えと同じである必要があります。 詳細については、 SQLおよびNLS照合のドキュメントの段落を参照してください。



テストクラスを作成します。

 Class Habr.test Extends %Persistent { Property Name As %String; Property Surname As %String; Index SurInd On Surname; ClassMethod populate() { do ..%KillExtent() set t = ..%New() set t.Name = "", t.Surname = "" write t.%Save() set t = ..%New() set t.Name = "", t.Surname = "" write t.%Save() set t = ..%New() set t.Name = "", t.Surname = "" write t.%Save() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データを入力します（その後、ドイツ語の例から名前を文字列に変更できます）。

 USER>do ##class(Habr.test).populate()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リクエストを実行します：









結果は予想外です。 主な質問は、名前のアルファベット順（ポール、ピーター、プロコール）ではないのはなぜですか？ リクエストプランを確認します。









この点でのキーワードは「populates temp-file」です。 クエリを実行するために、SQLオプティマイザーは、現在のプロセス（プロセスプライベートグローバル）のみに表示されるグローバル（場合によってはローカル配列）の一時構造（temp-file）を使用することを決定しました。 値はこのグローバルのインデックスに配置され、ソートされた順序で表示されます。 一時グローバルはCACHETEMPデータベースに格納され、Caché標準の新しいグローバルにソートされます。 しかし、なぜ「e」が最後ではなく最初にあるのでしょうか？ 一時グローバルのインデックスでは、名前フィールドの値はそれぞれ大文字に縮小され（ SQLUPPERは文字列のデフォルトの変換です ）、文字Eが先頭に付きます。



自動変換（ ％Exact関数）をキャンセルすると、まだ正しくないが、少なくとも予想される順序-「-」はすべての文字の後にソートされる









CACHETEMPのソートテーブルはまだ修正しません -姓のクエリをチェックします。 結局、この列には^ Habr.TestI globalにインデックスがあります。 このグローバルの並べ替えはCyrillic3であるため、行の順序はアルファベット順にする必要があります。







再びそうではありません。 私たちは計画を見ます：









元の形式で姓を表示するには（デフォルトでSurIndインデックス要素に適用されるSQLUPPER変換の前）、インデックスデータのみが小さく、テーブルにアクセスする必要があるため、SQLオプティマイザーはテーブルから直接データを取得して一時変数に並べ替えることを決定しました名前の場合。



リクエストで大文字が適切であると指定した場合、順序は正しくなります。結局、データはインデックスglobal ^ Habr.testIから直接取得されます。









予想されるリクエストプラン：









さて、以前にやらなければならなかったことをしましょう-CACHETEMPデータベースの新しいグローバルのデフォルトのソートをCyrillic3（またはCyrillic4）に変更します。



一時構造を使用するクエリは、正しい順序で行を出力するようになりました。

結論

• 文字withのデータが表示される順序を気にしない場合は、Caché標準照合テーブルを使用します。
• Cyrillic3を使用している場合、Cyrillic4照合テーブルを使用してアプリケーションをテストします。 アプリケーションはより高速になります。
• 同じ並べ替えテーブルがCACHETEMPデータベース、 運用データベース、およびロケール設定にあることを確認します。