自動増分キー

ほとんどのAdobe Campaign テーブルのプライマリキーは、データベースエンジンによって自動生成される 32 ビットの長い整数です。 キー値の計算は、データベース全体で一意の数値を生成するシーケンス (デフォルトでは XtkNewId SQL 関数)によって異なります。 レコードの挿入時に、キーの内容が自動的に入力されます。

増分キーの利点は、テーブル間の結合に変更不可能なテクニカルキーを提供することです。 さらに、このキーは 2 バイトの整数を使用するので、多くのメモリを占有しません。

ソーススキーマで、pkSequence 属性で使用するシーケンスの名前を指定できます。 この属性がソーススキーマで指定されていない場合は、デフォルトのシーケンス XtkNewId が使用されます。 nms:broadLog および nms:trackingLog スキーマ(それぞれ NmsBroadLogId および NmsTrackingLogId)は、レコード数が最も多いテーブルであるため、アプリケーションでは専用のシーケンスを使用します。

ACC 18.10 以降、XtkNewId は、標準スキーマのシーケンスのデフォルト値ではなくなりました。 これで、専用のシーケンスでスキーマを構築したり、既存のスキーマを拡張したりできるようになりました。

重要
スキーマを新しく作成するときや、スキーマを拡張するときは、スキーマ全体で同じプライマリキーのシーケンス値(@pkSequence)を保持する必要があります。

Adobe Campaign スキーマで参照されているシーケンス(NmsTrackingLogId など)は、パラメーター内の ID の数をコンマで区切って返す SQL 関数に関連付ける必要があります。 この関数は、GetNew XXX Ids と呼ぶ必要があります。XXX は、シーケンスの名前です(例:GetNewNmsTrackingLogIds)。 アプリケーションに付属の postgres-nms.sqlmssql-nms.sql または datakit/nms/eng/sql/ ディレクトリにあるoracle-nms.sql ファイルを表示し、各データベースエンジンの「NmsTrackingLogId」シーケンス作成の例を復元します

一意のキーを宣言するには、データスキーマのメイン要素の autopk 属性(値「true」)に入力します。

ソーススキーマでの増分キーの宣言:

<srcSchema name="recipient" namespace="cus">
  <element name="recipient" autopk="true">
  ...
  </element>
</srcSchema>

生成されたスキーマ:

<schema mappingType="sql" name="recipient" namespace="cus" xtkschema="xtk:schema">
  <element name="recipient" autopk="true" pkSequence="XtkNewId" sqltable="CusRecipient">
    <dbindex name="id" unique="true">
      <keyfield xpath="@id"/>
    </dbindex>

    <key internal="true" name="id">
      <keyfield xpath="@id"/>
    </key>

    <attribute desc="Internal primary key" label="Primary key" name="id" sqlname="iRecipientId" type="long"/>
  </element>
</schema>

キーとそのインデックスの定義に加えて、自動生成されたプライマリキーを格納するために、「id」と呼ばれる数値フィールドが拡張スキーマに追加されました。

重要
プライマリキーが 0 に設定されたレコードは、テーブルの作成時に自動的に挿入されます。このレコードは、外部結合を避けるために使用されます。外部結合はボリュームテーブルでは有効ではありません。デフォルトでは、外部キーはすべて値 0 で初期化されるので、データ項目が入力されていない場合でも常に、結合時に結果を返します。