開発時の機能と操作: 仮想キー
データリポジトリで設定するインデックスには、２つのタイプがあります。
実キーと仮想キーです。
デフォルトは実キーなので、特に意識せずに作成しているインデックスは全て実キーです。
まず、その両者の違いについて。
＜実キー＞
データベースに実際にインデックスとして登録されます。
従って、検索時に、そのインデックスが使われれば高速なレスポンスが期待できます。
＜仮想キー＞
データベースには、インデックスとして作成されません。
OracleやSQL Serverの管理画面で見ても、Magicで定義した仮想キーは探し出すことができません。
Magic内でのソート機能として使われます。
次に、設定方法について。
実キーは、特に意識する必要はないので、ここでは仮想キーについて話を進めます。
データリポジトリのインデックス定義画面で、インデックス行を作成し、名前を入力します。
インデックス特性を表示します。
Magic uniPaaSのデフォルトキーボード割付ならば、インデックス名のところで「Alt + Enter」です。
SQLタブのタイプ欄で、仮想キーを選択します。
これで、インデックス特性はOKです。
あとは、いつも通り、セグメント欄でソートしたい項目を選択します。
最後に、仮想キーを使う目的について。
インデックスとしての高速化が見込めない、データベースとハードウェアの能力頼みの仮想キーを何のために使うのでしょうか？
大きく分けて、次の２つかと思います。
１．ビュー（仮想表）を定義取得したとき
ビュー（データベースの仮想表：Create Viewで作成）を定義取得した場合、インデックスは「なし」の状態となります。
当然ながら、ビューに実キーは付けられませんから、定義取得としては、それで正しいわけです。
しかし、それではMagic内で使えません。
APGを実行するとエラーになります。
Magicでビューを使うには、ユニークインデックスが必須です。
実キーは付けられませんから、ユニークな仮想キーを付けることになります。
２．Pervasiveからの移行
DBMSをPervasiveから他のもの（OracleやSQL Server等）に変更する場合、インデックスを減らしたいと思うことがあります。
特にセグメント数の多いノンユニークインデックスは、検索時の高速化が期待薄であり、書込時の速度劣化が懸念されるので削除したい候補です。
Pervasive以外なら、インデックスなしでも、そこそこのレスポンスで実行できる可能性があるので、使用頻度の少ないインデックスはカットしたいのです。
あくまでも「そこそこ」の速度ですから、実際にはデータ件数と使用頻度とハードウェア性能と業務での影響などを考慮して、総合的に判断します。
ですが、データリポジトリからインデックスを削除してしまうと、それを使っていたタスクが誤動作する可能性が考えられます。
ソート順が変わってしまうので、グループ（ブレイク）処理が崩れるかもしれません。
このようなケースでは、データリポジトリからインデックスを削除するのではなく、仮想キーに変更しておけば、タスクへの影響を心配しなくても大丈夫ということになります。
他にも活用シーンがあるかもしれませんが、仮想キーは、設定しても高速化しない、ということだけは覚えておきましょう。