|
CREATE INDEX ステートメントを使用して、指定されたテーブルに名前付きインデックスを作成します。
CREATE [UNIQUE | PARTIAL] [NOT MODIFIABLE] INDEX インデックス名 [IN DICTIONARY] ON テーブル名 [インデックス定義] インデックス名 ::= ユーザー定義名 テーブル名 ::= ユーザー定義名 インデックス定義 ::= (インデックス セグメントの定義[, インデックス セグ メントの定義]...) インデックス セグメントの定義 ::= 列名 [ASC | DESC]
VARCHAR 型の列は、長さバイト(Btrieve lstring)またはゼロ終端バイト(Btrieve zstring)が予約され、有効な記憶データが 1 バイト少ない点が CHAR 型の列と異なります。言い換えると、CHAR (100) の列を作成すると、レコード内で 100 バイトを占めます。VARCHAR (100) は 101 バイトを占めます。
既存のデータ ファイルに対してリレーショナル インデックス定義を作成する(CREATE INDEX または CREATE INDEX IN DICTIONARY を使用する)たびに、Pervasive PSQL はそのファイルに定義されている Btrieve インデックスを自動的にチェックし、既存の Btrieve インデックスがリレーショナル インデックス定義に必要な属性のセットを提供しているかどうかを判定します。既存の Btrieve インデックスと作成する新しい定義が一致する場合は、リレーショナル インデックス定義と既存の Btrieve インデックスの間に関連付けが作成されます。一致するインデックスがない場合は、Pervasive PSQL は新しいインデックス定義を作成し、IN DICTIONARY が指定されていなければ、データ ファイルに新しいインデックスを作成します。
インデックス セグメントは、インデックス定義に使用した 1 つまたは複数の列に対応します。複数セグメントのインデックスは、複数列の組み合わせとして作成されたものです。
ファイルに定義するすべてのインデックスで使用できるセグメントの総数は、そのファイルのページ サイズによって異なります。
ヌル値を許可する列には考慮も必要です。たとえば、ページ サイズが 4096 バイトのデータ ファイルでは、1 ファイル当たりのインデックス セグメント数は 119 に制限されます。真のヌルがサポートされるインデックス付きのヌル値を許可する列には 2 つのセグメントから成るインデックスが必要なため、1 つのテーブルではインデックス付きのヌル値を許可する列(Btrieve ファイルでは、インデックス付きでヌル値を許可する真のヌル フィールド)は 59 個までしか持てません。ページ サイズが小さくなると、この制限も小さくなります。
ファイル バージョンを 7.x 以降に設定し、TRUENULLCREATE をデフォルト値のオンに設定して作成されたファイルはすべて、真のヌルをサポートします。以前のファイル形式で作成されたファイル、あるいは Pervasive.SQL 7 を使用するか TRUENULLCREATE をオフに設定して作成されたファイルは、真のヌルをサポートせず、この制限を受けません。
UNIQUE セグメント キーは、特定の行のセグメントの組み合わせがファイル内で重複しないことを保証します。これは、個々のセグメントが重複しないことを保証しませんし、要求もしません。
メモ
次のデータ型以外のすべてのデータ型にインデックスを設定できます。
BIT
LONGVARBINARY
LONGVARCHAR
BLOB
CLOB
『Status Codes and Messages』の 6008:セグメントが多すぎます。を参照してください。
CREATE INDEX ステートメントで PARTIAL キーワードを使用すると、長さの合計が 255 バイトを超える 1 つの列または列のグループでインデックスを作成できます。
部分インデックスは、大きな列のプレフィックスを使用して作成されるか、あるいは小さな列を複数組み合わせて作成されるため、大きな列のプレフィックスを用いた検索の方がより速く実行できます。したがって、WHERE 句で 'WHERE column_name LIKE 'prefix%' のような制限を使用しているクエリは、インデックスを何も使用しない場合とは対照的に、部分インデックスを使用することによって実行が速くなります。
CREATE INDEX ステートメントに PARTIAL キーワードを含めた場合、インデックス列の幅とオーバーヘッドが 255 バイト以上でなければ、PARTIAL キーワードは無視され、代わりに標準のインデックスが作成されます。
メモ
幅は列の実際のサイズを指し、オーバーヘッドはヌル インジケーターや文字列の長さなどを指します。
PARTIAL を使用する際には次の制限が適用されます。
WHERE 句が前述の制限事項に適合する場合は、実行プランを立てる際に部分インデックスが使用されます。
メモ
ALTER TABLE を使用して部分インデックス列の長さを変更したとき、変更後の長さが 255 バイトのインデックスに収まるようになった場合、あるいは 255 バイトを超えてしまった場合には、ユーザーの責任の下、ユーザーの要求に従って、そのインデックスの削除および再作成を行ってください。
次の例では、データ型とサイズの指定された PartID、PartName、SerialNo、および Description 列を含む、Part_tbl という名前のテーブルが作成されます。
CREATE TABLE part_tbl (partid INT, partname CHAR(50), serialno VARCHAR(200), description CHAR(300));
次に、Description 列を使って、idx_01 という名前の部分インデックスを作成します。
インデックスで使用される Description 列は 300 バイトありますが、PARTIAL キーワードを使用することにより、先頭の 255 バイト(オーバーヘッドを含む)だけをプレフィックスとしてインデックスで使用できるようになります。
次の例では、前の例と同じテーブルに idx_02 という部分インデックスを作成します。代わりに、この例では PartId、SerialNo、および Description 列をまとめてインデックスに使用します。
次の表は、どのようにして大きい列がインデックスに割り当てられるかを理解できるよう、インデックス列の詳細を示しています。
列名
|
データ型
|
サイズ
|
オーバーヘッド
|
インデックス内のサイズ
|
---|---|---|---|---|
PartID
|
Integer
|
4
|
|
4
|
SerialNo
|
Varchar
|
200
|
1
|
201
|
Description
|
Char
|
300
|
|
50
|
インデックスの合計サイズ
|
255
|
この属性は、インデックスが変更されないようにします。複数セグメントのインデックスでは、この属性はすべてのセグメントに適用されます。このセグメントのいずれかを変更しようとすると、ステータス コード 10:キー フィールドは変更できません。が返されます。
このキーワードを使用する目的は、基となる物理データは変更しないままで DDF に変更を加えたいことを、Pervasive PSQL に通知することです。
このキーワードをバウンド データベースで使うことはできません。
IN DICTIONARY は非常に強力で高度な機能です。これは、システム管理者によってのみ、もしくは絶対的に必要な場合にのみ使用してください。通常、Pervasive PSQL は DDF とデータ ファイルの完全な同期を保ちますが、この機能によりユーザーは、同期していないテーブルの辞書定義を既存のデータ ファイルに合致させることが柔軟に行えるようになります。これは、既存のデータ ファイルと合致する定義を辞書内に作成したい場合に有用です。
注意
DDF の変更を基となるデータ ファイルへの変更と並行して行わないと、不正な結果セット、パフォーマンスの問題、予期しない結果などの重大な問題が生じることがあります。
分離されたインデックス、つまり、DDF にのみ存在しデータ ファイルには存在しないインデックスを作成した場合、IN DICTIONARY を使用しないでそのインデックスを削除しようとすると、ステータス コード 6(不正なキー番号)が返されることがあります。このエラーは、データベース エンジンがデータ ファイルからインデックスを削除しようとしても、そのようなインデックスはデータ ファイルに存在しないために削除できないことから発生します。
SQL を使ってインデックスを作成する場合、Btrieve インデックス(キー)に割り当てる番号は制御できません。SQL を使って、インデックスが定義されていない Btrieve ファイルにインデックスを作成した場合、作成される最初のインデックスはインデックス #0、2 番目のインデックスはインデックス #1、というようになります。
Btrieve ファイルに既に 1 つ以上のインデックスが定義されている場合、SQL を介してインデックスを追加すると、インデックスが必要な属性を持っていて SQL インデックスに関連付けられていないことを確認するために、Pervasive PSQL によって Btrieve インデックスが調べられます。新しいインデックスのディスクリプションは INDEX.DDF に挿入されます。Pervasive PSQL が既存の Btrieve インデックスと合致する場合、挿入されたディスクリプションには既存インデックスのインデックス番号が含まれ、データ ファイルに新しい Btrieve インデックスは生成されません。
Pervasive PSQL が既存の Btrieve インデックスと合致しない場合は、未使用のインデックス番号のうち最小の番号がディスクリプションに指定されます。新しいインデックスのディスクリプションは INDEX.DDF に挿入されます。IN DICTIONARY が指定されていない場合は、ディスクリプションに指定されたインデックス番号を使って、データ ファイルに Btrieve インデックスが作成されます。
どのインデックス番号を使って INDEX.DDF に新しいインデックスを作成するかは指定できないため、インデックス番号を調べることは手動処理になります。まず、基となる Btrieve ファイルで BUTIL -STAT コマンドを発行し、Btrieve インデックスのリストを取得します。次に、X$Index を照会すると、どの SQL インデックス番号が次に使用されるかがわかります。
SELECT X$Index.* from X$Index WHERE Xi$file in (SELECT Xf$Id FROM X$File WHERE Xf$Name = 'tablename')
tablename はデータベース テーブルの名前に置き換えてください。
次の例では、Faculty テーブル内の Dept_name に基づいて、Dept という名のインデックスが作成されます。
次の例では、Person テーブルに変更できないセグメント インデックスが作成されます。
次の例では、データ ファイルと関連付けられない「デタッチされた」テーブルが作成され、その後でテーブル定義へのインデックスの追加と削除が行われます。このインデックスもまた、関連付けられる基となる Btrieve インデックスが存在しないため、分離されたインデックスとなります。
CREATE TABLE t1 IN DICTIONARY (c1 int, c2 int) CREATE INDEX idx_1 IN DICTIONARY on t1(c1) DROP INDEX t1.idx_1 IN DICTIONARY
|