CREATE TABLE
表定義を作成するには、次のようにCREATE TABLE文を使用します。
CREATE TABLE [IF NOT EXISTS] [namespace:]table-name
[COMMENT "comment string"]
(field-definition, field-definition-2 [,...]
PRIMARY KEY (field-name, field-name-2 [,...] ),
) [USING TTL ttl]
[IN REGIONS region-name,region-name-2 [,...]]説明:
-
IF NOT EXISTSオプションの句。この句を使用し、同じ名前と定義の表が現在のネームスペース内にすでに存在する場合、文によって新しい表が作成されず、エラーも返されません。アクションは発生しません。
IF NOT EXISTSを使用せず、同じ名前と定義の表が現在のネームスペースにすでに存在する場合は、文によって表の作成が試行され、失敗します。1つのネームスペースに同じ名前の表を2つ含めることはできません。 -
必須。表階層内のどこに存在するかにかかわらず、完全な表名を指定します。表は、デフォルトのネームスペース(table-namesysdefault)に作成されるトップレベルの表、デフォルト以外のネームスペース内の表あるいは親表の子表または孫表です。次のように、完全修飾表名を指定します。parent-table.child-table– 既存の親の新しい子表を指定します。子表を作成するには、親表の後にピリオド(.)を付け、その後に子の名前を指定します。たとえば、親表がUsersの場合、MailingAddressという子表をUsers.MailingAddressとして定義します。parent-table.child-table.grandchild-table- 既存の表の子表を指定します。Users.MailingAddress.Zipのように、親表も指定する必要があります。-
namespace-name:table-name- 特定のネームスペース(ユーザー作成のネームスペースまたはデフォルトのネームスペース(sysdefault:))内の新しい表を指定します。ネームスペースの後に接頭辞としてコロン(:)を付け、その後に新しい表名を指定します。ネームスペースの表の新しい子表、またはそれ以降の世代の場合は、Sales:Users.MailingAddressやSales:Users.MailingAddress.Zipなどの完全修飾表名を使用します。
-
COMMENTオプション。コメントを使用すると、表の簡単な説明を入力できます。コメントは実行時に解釈されませんが、表のメタデータの一部になります。
-
field-definition
必須。フィールドのカンマ区切りリスト。すべての表には1つ以上のフィールド定義があります。フィールド定義はこの項でこの後に説明します。
-
PRIMARY KEYすべての表で必須。主キーである表内のフィールドを1つ以上指定します。主キーの詳細は「主キー」を参照してください。
注意:
主キー・フィールドがINTEGERデータ型の場合、シリアライズされたサイズ制約を適用できます。詳細は、整数のシリアライズされた制約を参照してください。
オプションでシャード・キーを定義するには、主キー文で
SHARDキーワードを使用します。シャード・キーの詳細は「シャード・キー」を参照してください。次に例を示します。
PRIMARY KEY (SHARD(id), lastName) -
USING TTLオプション。表の行のデフォルトの存続時間の値を定義します。この句の詳細は、USING TTLを参照してください。注意:
最新リリースでは、TTL機能はこのプレビュー・リリースのMR表でサポートされていません。これは、今後のリリースで解除される一時的な制限です。 IN REGIONSオプション。作成される表がMR表である場合、このパラメータによって表がまたがるすべてのリージョンがリストされます。表をMR表として作成するには、この句に少なくとも1つのリモート・リージョンを指定する必要があります。MR表の詳細は、概要ガイドのMR表のライフ・サイクルを参照してください。
フィールド定義
表を定義する場合、フィールド定義は次の形式になります。
field-name type [constraints] [COMMENT "comment-string"] 説明:
-
field-nameはフィールドの名前です。たとえば、
idまたはfamiliarNameです。すべてのフィールドには名前が必要です。 -
typeはフィールドのデータ型を示します。INTEGERまたはSTRINGのようなシンプルな型、またはRECORDのような複合型にすることができます。使用可能な型のリストは次の項で説明します。
-
constraintsは、フィールドに含まれるデータの制約を説明します。つまり、許容範囲またはデフォルト値です。シーケンス・ジェネレータにより作成されるIDENTITYフィールドも使用できます。この情報はオプションです。詳細は、「フィールド制約」を参照してください。
-
COMMENTはオプションです。これは、フィールドの簡単な説明に使用できます。コメントは解釈されませんが、表のメタデータに入れられます。
サポートされるデータ型
表フィールドでは、次のデータ型がサポートされます。
-
ARRAYデータの配列です。配列のすべての要素は同じデータ型である必要があり、配列フィールドを定義するときにこの型を宣言する必要があります。たとえば、次のように文字列の配列を定義します。
myArray ARRAY(STRING) -
BINARYバイナリ・データ。
-
BINARY(length)長さ(バイト数)のサイズの固定長バイナリ・フィールド。
-
BOOLEANブール・データ型。
-
DOUBLE倍精度。
-
ENUM列挙リスト。フィールド定義では、使用可能な列挙値を指定する必要があります。次に例を示します。
fruitName ENUM(apple,pear,orange) -
FLOAT浮動小数。
-
INTEGER整数。
-
JSONJSON形式の文字列。
-
LONGロング。
-
MAPデータ・マップ。すべてのマップ・キーは文字列ですが、これらのフィールドを定義するときにはマップのデータ部分のデータ型を定義する必要があります。たとえば、キーが整数値にマップする場合、次のようにフィールドを定義します。
myMap MAP(INTEGER) -
数値
任意の型の数値または任意の値や精度を処理できる数値型。
-
RECORD埋込みレコード。フィールド定義は埋込みレコードに含まれるすべてのフィールドを定義する必要があります。適用される同じ構文ルールはすべて通常の表フィールドの定義に使用されます。たとえば、シンプルな埋込みレコードは次のように定義されます。
myEmbeddedRecord RECORD(firstField STRING, secondField INTEGER)データ制約、デフォルト値なども埋込みレコードのフィールド定義に使用できます。
-
STRING文字列。
-
TIMESTAMP(<precision>)ある時点を日付、およびオプションで時間値として表します。
タイムスタンプ値には、タイムスタンプが保持する秒の小数部を表す精度(0から9)があります。値を0に設定すると、小数秒は格納されません。3に設定すると、タイムスタンプにミリ秒が格納され、9に設定すると精度がナノ秒になります。タイムスタンプ・フィールドを宣言する場合は、精度が必要です。
フィールド制約
フィールド制約では、フィールドがNULLであるかどうか、行のデフォルト値が何であるかなど、フィールドに関する情報を定義します。すべてのデータ型が制約をサポートするわけではなく、各データ型がすべての使用可能な制約をサポートするわけではありません。
整数のシリアライズされた制約
INTEGERが主キー・フィールドに使用されている場合は、INTEGERデータ型にシリアライズされたサイズ制限を指定できます。これを行うと、ストア内のキーのサイズを減らすことができます。
これを行うには、主キー・フィールド名の後に(n)を使用します(nは整数で許可されるバイト数です)。nの意味のある範囲は1 - 4です。次に例を示します。
create table myId (id integer, primary key(id(3)))注意:
IDENTITYフィールドにバイト数の整数の制約値を指定することはできません。| バイト数 | 使用可能な整数値 |
|---|---|
| 1 | -63から63 |
| 2 | -8191から8191 |
| 3 | -1048575から1048575 |
| 4 | -134217727から134217727 |
| 5 | 任意の整数値 |
COMMENT
すべてのデータ型は制約の一部としてCOMMENTを受け入れられます。COMMENT文字列は解析されませんが、表のメタデータの一部になります。次に例を示します。
myRec RECORD(a STRING, b INTEGER) COMMENT "Comment string"USING TTL
USING TTLは、表の行に対するデフォルトの存続時間値を定義するオプションの文です。TTLの詳細は、Javaダイレクト・ドライバ開発者ガイドの存続時間の使用を参照してください。
指定する場合、この文ではttl値(0以上の整数)、空白、その後に時間単位としてhoursまたはdaysのいずれかを指定する必要があります。次に例を示します。
USING TTL 5 days 0が指定されている場合は、daysまたはhoursのいずれかを使用できます。値が0の場合、表の行に有効期限はありません。デフォルトTTLが表スキーマに適用されたことがない場合は、0がデフォルトになります。ただし、以前に表スキーマにデフォルトTTLを適用したことがあり、それをオフにする場合は、0 daysまたは0 hoursを使用します。
USING TTL 0 days 既存の表を変更する場合、同じALTER TABLE文を使用して、フィールドの追加/削除およびフィールドのデフォルトTTL値の変更の両方を実行することはできません。これら2つの操作は、別々の文を使用して実行する必要があります。
表作成例
前述した概念を示すために、次に例を記述します。
CREATE TABLE users
COMMENT "This comment applies to the table itself" (
id INTEGER,
firstName STRING,
lastName STRING,
age INTEGER,
PRIMARY KEY (id),
) CREATE TABLE temporary
COMMENT "These rows expire after 3 days" (
sku STRING,
id STRING,
price FLOAT,
count INTEGER,
PRIMARY KEY (sku),
) USING TTL 3 daysCREATE TABLE Users
COMMENT "This is an MR table"(
id INTEGER,
firstName STRING,
lastName STRING,
age INTEGER,
primary key (id)
) IN REGIONS us_east, us_west;CREATE TABLE usersNoId (
firstName STRING,
lastName STRING COMMENT "This comment applies to this field only",
age INTEGER,
ssn STRING NOT NULL DEFAULT "xxx-yy-zzzz",
PRIMARY KEY (SHARD(lastName), firstName)
) CREATE TABLE users.address (
streetNumber INTEGER,
streetName STRING, // this comment is ignored by the DDL parser
city STRING,
/* this comment is ignored */
zip INTEGER,
addrType ENUM (home, work, other),
PRIMARY KEY (addrType)
) CREATE TABLE complex
COMMENT "this comment goes into the table metadata" (
id INTEGER,
PRIMARY KEY (id), # this comment is just syntax
nestedMap MAP(RECORD( m MAP(FLOAT), a ARRAY(RECORD(age INTEGER)))),
address RECORD (street INTEGER, streetName STRING, city STRING, \
zip INTEGER COMMENT "zip comment"),
friends MAP (STRING),
floatArray ARRAY (FLOAT),
aFixedBinary BINARY(5),
days ENUM(mon, tue, wed, thur, fri, sat, sun) NOT NULL DEFAULT tue
) CREATE TABLE myJSON (
recordID INTEGER,
jsonData JSON,
PRIMARY KEY (recordID)
)