ON UPDATE 節を使用してテーブルを作成し、列を指定すると、その列はテーブルで行が更新されるたびに計算されます。この機能が最もよく使用されるのは、前回行が更新されたときのタイムスタンプ値を含むテーブルで列を定義する場合です。
CURRENT_DATE | CURRENT_TIME[(precision)] | CURRENT_TIMESTAMP[(precision)] | GETDATE([prec]) | GETUTCDATE([prec]) | SYSDATE | USER | CURRENT_USER | SESSION_USER | SYSTEM_USER | NULL | <literal> | -<number>
以下の例は、行の挿入時、および行の更新のたびに、RowTS 列を現在のタイムスタンプ値に設定します。
CREATE TABLE mytest (
Name VARCHAR(48),
RowTS TIMESTAMP DEFAULT Current_Timestamp(6) ON UPDATE Current_Timestamp(6) )
この例で、DEFAULT キーワードは、INSERT 時に RowTS 列に明示的な値が指定されていない場合、この RowTS に現在のタイムスタンプを設定します。UPDATE が RowTS 列に明示的な値を指定した場合、ON UPDATE キーワードは指定された値を検証しますが、これを無視し、RowTS を現在のタイムスタンプで更新します。指定された値が検証に失敗した場合、SQLCODE -105 エラーが生成されます。
以下の例では、HasBeenUpdated 列をブーリアン値に設定します。
CREATE TABLE mytest (
Name VARCHAR(48),
HasBeenUpdated TINYINT DEFAULT 0 ON UPDATE 1 )
以下の例では、WhoLastUpdated 列を現在のユーザ名に設定します。
CREATE TABLE mytest (
Name VARCHAR(48),
WhoLastUpdated VARCHAR(48) DEFAULT CURRENT_USER ON UPDATE CURRENT_USER )
列に COMPUTECODE データ制約も存在する場合、ON UPDATE 節を指定することはできません。それらを参照すると、コンパイルまたは準備時に SQLCODE -1 エラーが返されます。
description
InterSystems SQL で提供されている %DESCRIPTION キーワードは、テーブルまたは列の説明を挿入するために使用します。%DESCRIPTION の後には、一重引用符で囲んだテキスト文字列の description を続けます。このテキストの長さに制限はなく、空白スペースを含むすべての文字を使用できます(説明文字列内の一重引用符は、二重引用符で代用します。例えば、'Joe''s Table' のようになります)。1 つのテーブルには 1 つの %DESCRIPTION を使用できます。テーブルの各列には、データ型の後にそれぞれ独自の %DESCRIPTION を指定できます。テーブル全体の %DESCRIPTION を複数指定すると、SQLCODE -82 エラーが発行されます。列の %DESCRIPTION を複数指定すると、最後に指定された %DESCRIPTION のみが保持されます。ALTER TABLE を使用して既存の説明を変更することはできません。
対応する永続クラス定義では、説明は、対応するクラス (テーブル) 構文またはプロパティ (列) 構文の 1 つ前の行に、3 つのスラッシュが付けられて表示されます。例えば、/// Joe's Table のようになります。対応する永続クラスの "クラス・リファレンス" では、テーブルの説明は、上部のクラス名と SQL テーブル名の直後に表示されます。列の説明は、対応するプロパティ構文の直後に表示されます。
%DESCRIPTION テキストを表示するには、INFORMATION.SCHEMA.TABLESOpens in a new tab または INFORMATION.SCHEMA.COLUMNSOpens in a new tab の DESCRIPTION プロパティを使用します。例:
SELECT COLUMN_NAME,DESCRIPTION FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='MyTable'
sqlCollation
列の値をソートするために使用される照合タイプ。SQL 照合タイプ (%EXACT、%MINUS、%PLUS、%SPACE、%SQLSTRING、%SQLUPPER、%TRUNCATE、または %MVR) のいずれかとして指定します。照合のキーワードでは、大文字と小文字は区別しません。プログラミングを明確にする目的で、照合パラメータの前にオプション・キーワードの COLLATE を指定することを推奨します。ただし、このキーワードは必須ではありません。これらのさまざまな照合パラメータ・キーワードの先頭のパーセント記号 (%) もオプションです。
既定は、ネームスペースの既定の照合です (変更していない場合は %SQLUPPER です)。%SQLSTRING、%SQLUPPER、および %TRUNCATE は、オプションの最大長のトランケーション引数である、括弧で囲んだ整数を指定できます。照合の詳細は、"テーブルのフィールド/プロパティ定義の照合" を参照してください。
%EXACT 照合は、ANSI (または Unicode) 文字の照合順に従います。大文字/小文字を区別する文字列照合を行い、先頭および末尾の空白およびタブ文字を認識します。
%SQLUPPER 照合は、照合目的ですべての文字を大文字に変換します。大文字と小文字を区別しない照合の詳細は、"%SQLUPPER" 関数を参照してください。
%SPACE および %SQLUPPER 照合はデータに空白を追加します。これにより、NULL と数値の文字列照合が強制されます。
%SQLSTRING、%SQLUPPER、および %STRING 照合では、括弧で囲む必要のある maxlen パラメータをオプションで使うことができます。maxlen は切り捨てを命令する整数で、照合の実行時に対象とする最大文字数を指定します。このパラメータは、サイズの大きなデータ値を持つ列にインデックスを作成するときに便利です。
%PLUS および %MINUS 照合は、NULL をゼロ (0) 値として処理します。
InterSystems SQL には、これらの照合タイプのほとんどに対応する関数があります。詳細は、%EXACT、%SQLSTRING、%SQLUPPER、%TRUNCATE の各関数を参照してください。
ObjectScript では、データ照合変換のために %SYSTEM.UtilOpens in a new tab クラスの Collation()Opens in a new tab メソッドが提供されています。
Note:
ネームスペースの既定の照合を %SQLUPPER (大文字/小文字の区別なし) から %SQLSTRING (大文字/小文字の区別あり) などの他の照合タイプに変更するには、以下のコマンドを使用します。
WRITE $$SetEnvironment^%apiOBJ("collation","%Library.String","SQLSTRING")
このコマンドを発行した後に、インデックスを削除し、すべてのクラスを再コンパイルしてから、再度インデックスを構築する必要があります。他のユーザがテーブルのデータにアクセスしている間はインデックスを再構築しないでください。再構築すると、クエリ結果が不正確になる可能性があります。
shardKeyColumn
シャード・キーとして使用される 1 つの列または列のコンマ区切りのリストです。shardKeyColumn は、SHARD KEY 節内のテーブル列リストの閉じ括弧の直後、かつ WITH 節 (指定される場合) の前に指定します。シャード・キー定義をテーブル列リスト内の要素として指定することは、下位互換性保持のためにサポートされていますが、両方の場所でシャード・キーを定義すると、SQLCODE -327 エラーが生成されます。
RowID 列をシャード・キーとして定義することはできません。ただし、作成されたテーブルに IDENTITY 列または IDKEY が含まれている場合は、これらの列のどちらかをシャード・キーとして定義できます。
シャード・キーの選択の詳細は、"シャード・キーの選択" を参照してください。
coshardKeyColumn
coshardTable で定義したテーブルのシャード・キーとのコシャード結合で使用するシャード・キー列の名前です。coshardKeyColumn は、COSHARD WITH 構文 (SHARD KEY (coshardKeyColumn) COSHARD WITH coshardTable) で指定します。
coshardTable
作成中のテーブルがコシャードする既存のテーブルの名前。COSHARD WITH 節で指定されたテーブルは、システムによって割り当てられたシャード・キーを持つシャード・テーブルである必要があります。
このテーブルを指定すると、シャード・テーブルの ShardKey インデックスに CoshardWith インデックス・キーワードが設定されます。この CoshardWith インデックス・キーワードは、テーブルを投影するクラスと等しくなります。
クエリで指定したどのシャード・テーブルがコシャードされるか確認するには、Cosharding コメント・オプションを表示します。
例
テーブルの作成および生成
CREATE TABLE を使用して、複数の列を持つテーブル Employee を作成します。
-
EmpNum 列 (会社の従業員の ID 番号を含む) は、NULL ではない整数です。また、テーブルの主キーとして宣言され、テーブルに行が挿入されるたびに自動的にインクリメントされます。
-
従業員の姓と名は、最大 30 文字で NULL にはできない文字列の列に格納されます。
-
残りの列には、従業員の入社日や有給休暇、病欠日を格納します。これらの列には TIMESTAMP および INT データ型を使用します。
CREATE TABLE Employee (
EmpNum INT NOT NULL AUTO_INCREMENT,
NameLast CHAR(30) NOT NULL,
NameFirst CHAR(30) NOT NULL,
StartDate TIMESTAMP,
AccruedVacation INT,
AccruedSickLeave INT,
CONSTRAINT EMPLOYEEPK PRIMARY KEY (EmpNum))
テーブル・スキーマを変更するには、ALTER TABLE を使用します。例えば、この文はテーブルの名前を Employee から Employees に変更します。
ALTER TABLE Employee RENAME Employees
テーブルに行を挿入するには、INSERT を使用します。例えば、この文はテーブルに必要な列のみを持つ行を挿入します。EmpNum 列も必要ですが、これは自動インクリメントされるため、指定する必要はありません。
INSERT INTO Employees (NameLast, NameFirst) VALUES ('Zubik','Jules')
挿入された行を更新するには、UPDATE を使用します。例えば、挿入された行で、この文はデータが欠落している列の 1 つに値を設定します。
UPDATE Employees SET AccruedVacation = 15 WHERE Employees.EmpNum = 1
行を削除するには、DELETE を使用します。例えば、この文は挿入された行を削除します。
DELETE FROM Employess WHERE EmpNum = 1
テーブル全体を削除するには、DROP TABLE を使用します。DROP TABLE の使用には注意が必要です。%NODELDATA キーワードを指定しない限り、このコマンドはテーブルとすべての関連付けられたデータの両方を削除します。
DROP TABLE Employess
セキュリティおよび特権
CREATE TABLE コマンドは、%CREATE_TABLE の管理者権限を必要とする、特権の必要な操作です。特権なしで CREATE TABLE コマンドを実行すると、SQLCODE -99 エラーが返されます。%CREATE_TABLE 特権をユーザまたはロールに割り当てるには、GRANT コマンドを使用します。この場合、適切な付与特権を保持していることを前提とします。CREATE TABLE AS SELECT 構文を使用する場合、query で指定されるテーブル上で SELECT 特権が必要です。管理特権はネームスペース固有のものです。詳細は、"特権" を参照してください。
既定では、CREATE TABLE のセキュリティ特権が適用されます。システム全体でこの特権の要件を構成するには、$SYSTEM.SQL.Util.SetOption()Opens in a new tab メソッドを使用します。例: SET status=$SYSTEM.SQL.Util.SetOption("SQLSecurity",0,.oldval)現在の設定を確認するには、$SYSTEM.SQL.CurrentSettings()Opens in a new tab メソッドを呼び出します。これにより、[SQL セキュリティ有効] の設定が表示されます。既定値は 1 (有効) です。SQL セキュリティが有効な場合 (推奨)、ユーザは特権を保持しているテーブルやビューのみでアクションを実行できます。このメソッドを 0 に設定すると、この設定の変更後に開始された新しいプロセスすべてで SQL セキュリティは無効になります。つまり、特権ベースのテーブルやビューのセキュリティは抑制されていることを意味します。ユーザを指定しなくてもテーブルの作成が可能になります。この場合、ダイナミック SQL はユーザとして “_SYSTEM” を、埋め込み SQL はユーザとして "" (空文字列) を割り当てます。ユーザは特権がなくてもテーブルやビューに対してアクションを実行することができます。
埋め込み SQL は、SQL 特権を使用しません。埋め込み SQL では、以下のように $SYSTEM.Security.Login()Opens in a new tab メソッドを使用して適切な特権を持ったユーザとしてログインできます。$SYSTEM.Security.Login() メソッドを呼び出すには、%Service_Login:Use 特権が必要です。例:
DO $SYSTEM.Security.Login("_SYSTEM","SYS")
NEW SQLCODE,%msg
&sql(CREATE TABLE MyTable (col1 INT, col2 INT))
IF SQLCODE=0 {WRITE !,"Table created"}
ELSE {WRITE !,"SQLCODE=",SQLCODE,": ",%msg }
詳細は、"%SYSTEM.SecurityOpens in a new tab" を参照してください。
実行コードを必要とする計算済み列で CREATE TABLE を使用する場合は、%CREATE_TABLE 特権のほかに %Development:USE 特権が必要です。ただし、このコマンドを埋め込み SQL で使用する場合を除きます。
また、%SQL.StatementOpens in a new tab クラスのコマンドを作成し、checkPriv 引数を 0 に設定した %Prepare() メソッドまたは %ExecDirectNoPriv() メソッドを使用して、特権の確認を回避することもできます。
詳細
主キーの定義
主キーの定義はオプションです。テーブルを定義すると、生成列 RowID 列 (既定名 "ID") が自動的に作成されます。これは一意の行識別子として機能します。各レコードがテーブルに追加されると、InterSystems IRIS はそのレコードの RowID 列に、変更できない一意の正の整数を割り当てます。オプションで、一意の行識別子としても機能する主キーを定義できます。主キーにより、ユーザはアプリケーションにとって意味のある行識別子を定義できます。例えば、主キーは、従業員 ID 列、社会保障番号、患者レコード ID 列、在庫ストック番号などになります。PRIMARY KEY 節を使用して、列または列のグループを主レコード識別子として明示的に定義することができます。
主キーには、重複する値や NULL 値は設定できません (主キー・インデックス・プロパティは自動的に必須として定義されるわけではありませんが、主キー列には NULL 値を保存できないので、事実上、必須です)。主キーの照合タイプは、列そのものの定義で指定されます。
主キーとして定義されているテーブルの列をリストする方法は、"[カタログの詳細] の [制約] オプション" を参照してください。
詳細は、"主キー" を参照してください。
IDKEY の主キー
既定では、主キーは一意の IDKEY インデックスではありません。通常は、主キー値の更新や、主キーの照合タイプの設定などを行えるため、既定を推奨します。ただし、主キーを IDKEY インデックスとして定義する方が好ましい場合もあります。その場合は、その後主キーを使用するにあたって IDKEY が制限されることを考慮する必要があります。
既存の列に主キー制約を追加する場合、列が自動的に IDKEY インデックスとして定義されることもあります。これはデータが存在するかどうか、および構成設定が以下のいずれかの方法で設定されているかどうかによります。
ただし、IDENTITY 列がテーブルで定義済みであると、これらの構成設定のいずれかを使用して主キーを IDKEY として定義していても、主キーを IDKEY として定義することはできません。
InterSystems IRIS では、IDKEY インデックスに属するプロパティ (列) を SqlComputed にすることができます。例えば、親参照列などです。このプロパティは、トリガによって計算される列とする必要があります。SqlComputed として定義した IDKEY プロパティは、新規オブジェクトを初めて保存するときまたは INSERT 操作のときにのみ計算されます。UPDATE 計算は、IDKEY インデックスに属する列を更新できないため、サポートされていません。
主キーなし
多くの場合、明示的に主キーを定義する必要があります。ただし、主キーが指定されない場合、InterSystems IRIS では、以下のルールに基づいて、別の列を ODBC/JDBC プロジェクションの主キーとして使用します。
-
単一の列上に IDKEY インデックスが存在する場合、IDKEY 列を SQLPrimaryKey 列として報告する。
-
そうでない場合、クラスが SqlRowIdPrivate=0 (既定) で定義されていれば、RowID 列を SQLPrimaryKey 列として報告する。
-
そうでない場合、IDKEY インデックスが存在すると、IDKEY 列を SQLPrimaryKey 列として報告する。
-
そうでない場合、SQLPrimaryKey を報告しない。
複数の主キー
主キーは 1 つしか定義できません。既定では、InterSystems IRIS は、主キーが既に存在する場合に主キーを定義しようとしたり、同じ主キーを 2 回定義しようとしたりすると、それを拒否して SQLCODE -307 エラーを発行します。主キーの第 2 定義が最初の定義と同じ場合も SQLCODE -307 エラーを発行します。現在の構成を確認するには、$SYSTEM.SQL.CurrentSettings()Opens in a new tab を呼び出します。これにより、[既存キーに対して DDL の Create Primary Key を許可] 設定が表示されます。既定値は 0 (いいえ) で、これが推奨される構成設定です。このオプションが 1 (はい) に設定されている場合、InterSystems IRIS は既存の主キー制約を削除し、最後に指定された主キーをテーブルの主キーとして設定します。
管理ポータル、[システム管理]、[構成]、[SQL とオブジェクトの設定]、[SQL] から [冗長な DDL ステートメントを無視] チェック・ボックスにチェックを付けることにより、このオプション (および他の同様の作成、変更、および削除のオプション) をシステム全体で設定できます。
例えば、以下に CREATE TABLE 文があります。
CREATE TABLE MyTable (f1 VARCHAR(16),
CONSTRAINT MyTablePK PRIMARY KEY (f1))
この文は、主キーを作成します (存在しない場合)。次に、ALTER TABLE 文があります。
ALTER TABLE MyTable ADD CONSTRAINT MyTablePK PRIMARY KEY (f1)
上記の例は、SQLCODE -307 エラーを生成します。
外部キーの定義
外部キーは他のテーブルを参照する列です。外部キー列に保存された値は、他のテーブル内のレコードを一意に識別します。この参照の最も単純な形式を以下の例に示します。この例では、外部キーが Customers テーブルの主キー列 CustID を暗黙的に参照しています。
CREATE TABLE Orders (
OrderID INT UNIQUE NOT NULL,
OrderItem VARCHAR,
OrderQuantity INT,
CustomerNum INT,
CONSTRAINT OrdersPK PRIMARY KEY (OrderID),
CONSTRAINT CustomersFK FOREIGN KEY (CustomerNum) REFERENCES Customers (CustID))
通常、外部キーは他のテーブルの主キー列を参照します。ただし、外部キーは RowID (ID) または IDENTITY 列を参照できます。外部キー参照は参照されるテーブルに常に存在し、一意として定義される必要があります。参照される列は重複値または NULL を持つことはできません。
外部キー定義では以下の内容を指定できます。
-
1 つの列名: FOREIGN KEY (CustomerNum) REFERENCES Customers (CustID)。外部キー列 (CustomerNum) および参照される列 (CustID) は異なる名前でも (同じ名前でも) かまいませんが、データ型と列の制約は同じでなければなりません。
-
コンマで区切られた列名のリスト: FOREIGN KEY (CustomerNum,SalespersonNum) REFERENCES Customers (CustID,SalespID)。外部キー列および参照される列は、列の数およびリストでの順序が一致している必要があります。
-
省略された列名: FOREIGN KEY (CustomerNum) REFERENCES Customers。
-
明示的な RowID 列: FOREIGN KEY (CustomerNum) REFERENCES Customers (%ID)。省略された列名と同義です。テーブルのクラス定義に SqlRowIdName が含まれる場合、この値を明示的な RowID として指定できます。
外部キーを定義して、参照される列名を省略した場合、外部キーの既定は次のようになります。
-
指定されたテーブルで定義されている主キー列。
-
指定されたテーブルに主キーが定義されていない場合、外部キーの既定は指定されたテーブルで定義されている IDENTITY 列になります。
-
指定されたテーブルに主キーも IDENTITY 列も定義されていない場合、外部キーの既定は RowID になります。これが発生するのは、指定されたテーブルで RowID をパブリックとして定義した場合のみです。指定されたテーブル定義でこれを明示的に行うには、%PUBLICROWID キーワードを指定するか、対応するクラス定義で SqlRowIdPrivate=0 (既定) を指定します。指定されたテーブルで RowID をパブリックとして定義していない場合、InterSystems IRIS は SQLCODE -315 エラーを発行します。RowID で外部キーを定義する際は、参照される列名を省略する必要があります。ID を参照される列名として明示的に指定しようとすると、SQLCODE -316 エラーが発生します。
上記のいずれの既定も適用されない場合は、SQLCODE -315 エラーが発行されます。
外部キー列および外部キーに対して生成された制約名として定義されているテーブルの列をリストする方法は、"[カタログの詳細] の [制約] オプション" を参照してください。
次の例に示すように、クラス定義では、親テーブルの IDKEY プロパティに基づく列を含む外部キーを指定できます。
ForeignKey Claim(CheckWriterPost.Hmo,Id,Claim) References SQLUser.Claim.Claim(DBMSKeyIndex);
子の外部キーに定義された親列は親クラスの IDKEY インデックスの一部である必要があるため、このタイプの外部キーでサポートされている参照アクションは NO ACTION のみです。
-
存在しないテーブルを外部キーで参照すると、SQLCODE -310 エラーが発行され、%msg に補足情報が示されます。
-
存在しない列を外部キーで参照すると、SQLCODE -316 エラーが発行され、%msg に補足情報が示されます。
-
一意ではない列を外部キーで参照すると、SQLCODE -314 エラーが発行され、%msg に補足情報が示されます。
外部キー列が 1 つの列を参照する場合は、2 つの列で、データ型と列のデータ制約が同じである必要があります。
親子リレーションシップでは、子の順序は定義されていません。アプリケーション・コードは特定の順序に依存しないでください。
読み取り専用としてマウントされたデータベースのクラスを参照する外部キー制約を定義できます。FOREIGN KEY を定義するには、ユーザは、参照されるテーブルまたは参照されるテーブルの列の REFERENCES 特権を持っている必要があります。REFERENCES 特権は、ダイナミック SQL または xDBC を介して CREATE TABLE を実行する場合に必要になります。
シャード・テーブルと外部キー
キー・テーブルがシャード化され、外部キー・テーブルがシャード化されていない場合、キー・テーブルがシャード化されておらず、外部キー・テーブルがシャード化されている場合、キー・テーブルと外部キー・テーブルの両方がシャード化されている場合など、シャード・テーブルとシャード化されていないテーブルのあらゆる組み合わせについて、外部キーがサポートされています。参照されるテーブルのキーはシャード・キーでも別のキーでもかまいません。外部キーは 1 つの列でも、複数の列でもかまいません。
NO ACTION は、シャード・テーブルでサポートされている唯一の参照アクションです。
詳細は、"シャード・クラスタにおけるクエリ" を参照してください。
暗黙的な外部キー
すべての外部キーは明示的に定義することをお勧めします。明示的な外部キーが定義されている場合、InterSystems IRIS はこの制約を報告し、暗黙的な外部キー制約は定義されません。
ただし、暗黙的な外部キーを ODBC/JDBC および管理ポータルに投影することもできます。これらの暗黙的な外部キーは、NO ACTION の UPDATE および DELETE 参照アクションとして報告されます。参照アクションが適用されていないため、この暗黙的な参照外部キーは、真の外部キーではありません。この参照に対して報告されるこの外部キーの名前は、"IMPLICIT_FKEY_REFERENCE__"_columnname となります。この参照を外部キーとして報告する動作は、サードパーティ製ツールとの相互運用性のために提供されています。
ビットマップ・エクステント・インデックス
CREATE TABLE を使用してテーブルを作成する場合、既定では、InterSystems IRIS は自動的に対応するクラスのビットマップ・エクステント・インデックスを定義します。ビットマップ・エクステント・インデックスの SQL マップ名は、%%DDLBEIndex です。
Index DDLBEIndex [ Extent, SqlName = "%%DDLBEIndex", Type = bitmap ];
このビットマップ・エクステント・インデックスは、以下の状況では作成されません。
ビットマップ・インデックスを作成した後に、CREATE BITMAPEXTENT INDEX コマンドを、ビットマップ・エクステント・インデックスが自動的に定義されたテーブルに対して実行すると、それ以前に定義されているビットマップ・エクステント・インデックスは、CREATE BITMAPEXTENT INDEX 文により指定された名前に変更されます。
既存のビットマップ・エクステント・インデックスを自動的に削除する DDL 操作については、“ALTER TABLE” を参照してください。
詳細は、"ビットマップ・エクステント・インデックス" を参照してください。
IDENTITY キーワードを使用した名前付き RowId 列の作成
InterSystems SQL では、テーブルごとに RowID 列が自動的に作成されます。この列には、一意のレコード ID となるシステム生成の整数が格納されます。オプションの IDENTITY キーワードを使用すると、RowID レコード ID 列と同じプロパティを持つ名前付きの列を定義できます。IDENTITY 列は、システムが生成する一意の整数値を値として持つ単一列の IDKEY インデックスとして動作します。
IDENTITY 列を定義することにより、IDKEY としての主キーの定義が回避されます。
システムが生成するあらゆる ID 列と同様に、IDENTITY 列は以下の特性を持ちます。
-
IDENTITY 列として定義できるのは、テーブルごとに 1 つの列のみです。複数の IDENTITY 列を定義しようとすると、SQLCODE -308 エラーが発生します。
-
IDENTITY 列のデータ型は整数データ型であることが必要です。データ型を指定しないと、データ型は自動的に BIGINT として定義されます。INTEGER や SMALLINT など、任意の整数データ型を指定できます。RowID のデータ型と一致するように BIGINT を使用することをお勧めします。NOT NULL や UNIQUE のような列制約は受け入れられますが無視されます。
-
データ値はシステムが生成します。値は一意で、0 以外の正の整数です。
-
既定では、IDENTITY 列のデータ値をユーザが指定することはできません。既定では、INSERT 文は IDENTITY 列の値を指定しません。指定しようとしてもできません。これを実行しようとすると、SQLCODE -111 エラーが生成されます。IDENTITY 列の値を指定できるかどうかを確認するには、$SYSTEM.SQL.Util.GetOption("IdentityInsert")Opens in a new tab メソッドを呼び出します。既定値は 0 です。現在のプロセスに対してこの設定を変更するには、$SYSTEM.SQL.Util.SetOption()Opens in a new tab メソッドを SET status=$SYSTEM.SQL.Util.SetOption("IdentityInsert",1,.oldval) のように呼び出します。テーブル定義で %CLASSPARAMETER ALLOWIDENTITYINSERT=1 を指定することもできます。ALLOWIDENTITYINSERT=1 を指定すると、SetOption("IdentityInsert") を使用して適用された設定がオーバーライドされます。詳細は、"INSERT" 文を参照してください。
-
IDENTITY 列のデータ値を UPDATE 文で変更することはできません。これを実行しようとすると、SQLCODE -107 エラーが生成されます。
-
システムが自動的に、IDENTITY 列上の主キーを ODBC および JDBC に投影します。CREATE TABLE 文または ALTER TABLE 文によって、IDENTITY 列または IDENTITY 列を含む列セット上に主キー制約または一意の制約を定義すると、その制約定義は無視されます。したがって、対応する主キーまたは一意のインデックス定義が作成されることはありません。
-
SELECT * 文はテーブルの IDENTITY 列を返します。
INSERT、UPDATE、または DELETE 操作に続いて LAST_IDENTITY 関数を使用すると、直前に変更したレコードの IDENTITY 列の値を返すことができます。IDENTITY 列が定義されていない場合、LAST_IDENTITY は直前に変更したレコードの RowID 値を返します。
これらの SQL 文は、IDENTITY 列を持つテーブルを作成し、そのテーブルに行を挿入し、作成されたテーブルに対して IDENTITY 列の値を生成します。
CREATE TABLE Employee (
EmpNum INT NOT NULL,
MyID IDENTITY NOT NULL,
Name VARCHAR(30) NOT NULL,
CONSTRAINT EmployeePK PRIMARY KEY (EmpNum))
INSERT INTO Employee (EmpNum,Name)
SELECT ID,Name FROM SQLUser.Person WHERE Age >= '25'
この場合、主キー EmpNum は別のテーブルの ID 列から取得されます。EmpNum の値は一意の整数になりますが、WHERE 節のため、この列の数字が連続しない場合もあります。IDENTITY 列の MyID は、ユーザから可視の一意の連続した整数を、各レコードに割り当てます。
シャード・テーブルの制限事項
シャード・テーブルを定義する際は、以下の制限があることに留意してください。
-
シャード・テーブルはシャード環境でのみ使用できます。シャード化されていないテーブルは、シャード環境またはシャード化されていない環境で使用できます。すべてのテーブルがシャーディングに適した候補とは限りません。シャード環境で最適なパフォーマンスを得るには、一般に、シャード・テーブル (一般的に非常に大きなテーブル) とシャード化されていないテーブルの組み合わせを使用します。詳細は、"シャーディングの効果の評価" および "シャーディングに関する既存のテーブルの評価" を参照してください。
-
CREATE TABLE または永続クラス定義のいずれかを使用して、シャード・テーブルとしてテーブルを定義する必要があります。ALTER TABLE を使用して、シャード・キーを既存のテーブルに追加することはできません。
-
シャード・キーが一意キーのサブセットでない限り、シャード・テーブル列の一意制約によって、挿入/更新のパフォーマンスに重大な悪影響が生じることがあります。詳細は、“シャーディングによるデータ量に応じた InterSystems IRIS の水平方向の拡張” にある "一意制約の評価" を参照してください。
-
アトミック性を必要とする複雑なトランザクションに含まれるテーブルをシャード化することはお勧めしません。
-
シャード・テーブルに ROWVERSION データ型または SERIAL (%Library.Counter) データ型の列を含めることはできません。
-
シャード・テーブルでは、VERSIONPROPERTYOpens in a new tab クラス・パラメータを指定することはできません。
-
シャード・キーを指定するには、現在のネームスペースがシャーディング用に構成されている必要があります。現在のネームスペースがシャーディング用に構成されていない場合、シャード・キーを指定した CREATE TABLE は SQLCODE -400 エラーで失敗します。シャーディング用のネームスペースの構成の詳細は、"シャード・マスタ・データ・サーバの構成" を参照してください。
-
シャード・テーブルでサポートされている唯一の参照アクションは、NO ACTION です。他の参照アクションはすべて、SQLCODE -400 エラーになります。
-
シャード・キー列では、%EXACT、%SQLSTRING、または %SQLUPPER 照合のみを使用でき、切り捨ては行われません。詳細は、"シャード・クラスタにおけるクエリ" を参照してください。
シャーディングの詳細は、"ターゲット・シャード・テーブルの作成" を参照してください。
レガシー・オプション
%EXTENTSIZE キーワードと %NUMROWS キーワード
%EXTENTSIZE キーワードと %NUMROWS キーワードは、作成中のテーブルに想定される行数を格納するためのオプションを提供します。InterSystems SQL クエリ・オプティマイザは、この値を使用してクエリ・プランのコストを見積もります。テーブルでこれらの値のいずれかを定義できますが、両方はできません。例:
CREATE TABLE Sample.DaysInAYear (
%EXTENTSIZE 366,
MonthName VARCHAR(24),
Day INTEGER)
2021 年 2 月以降、テーブルに対して初めてクエリを実行するときに、InterSystems IRIS はテーブル・サイズなどの統計を自動的に収集します。SQL クエリ・オプティマイザはこれらの生成された統計を使用してクエリ・プランを提案するため、%EXTENTSIZE キーワードと %NUMROWS キーワードが不要になります。テーブル統計を使用したテーブルの最適化の詳細は、"クエリ・オプティマイザで使用するテーブル統計" を参照してください。
%FILE キーワード
%FILE キーワードは、テーブルを示すファイル名を指定するオプションを提供します。例:
CREATE TABLE Employee (
%FILE 'C:\SQL\employee_table_desc.txt',
EmpNum INT PRIMARY KEY,
NameLast VARCHAR(30) NOT NULL,
NameFirst VARCHAR(30) NOT NULL,
StartDate TIMESTAMP %Description 'MM/DD/YY')
このキーワードは推奨されません。代わりに、%DESCRIPTION キーワードを使用してテーブルについて説明します。
列リストの括弧内のシャード・キーと %CLASSPARAMETER
古い CREATE TABLE コードには、シャード・キー定義と %CLASSPARAMETER 節が、テーブル要素を含む括弧内にコンマで区切られた要素として含まれる場合があります。例: CREATE TABLE myTable(Name VARCHAR(50), DOB DATE, %CLASSPARAMETER USEEXTENTSET = 1)。これらの節を閉じ括弧の後に指定する構文を推奨します。例: CREATE TABLE myTable(Name VARCHAR(50), DOB TIMESTAMP) WITH %CLASSPARAMETER USEEXTENTSET = 1。これらの節を重複して指定すると、SQLCODE -327 エラーが生成されます。
互換性のみにサポートされるオプション
InterSystems SQL は、構文解析の目的にのみ以下の CREATE TABLE オプションをサポートし、既存の SQL コードから InterSystems SQL への変換を支援します。これらのオプションは、実際には機能しません。
{ON | IN} dbspace-name LOCK MODE [ROW | PAGE] [CLUSTERED | NONCLUSTERED] WITH FILLFACTOR = literal MATCH [FULL | PARTIAL] CHARACTER SET identifier COLLATE identifier /* But COLLATE keyword is still used*/ NOT FOR REPLICATION
関連項目
FeedbackOpens in a new tab