既存のテーブルを参照するスキーマの特性は次のとおりです。
組み込みの受信者テーブルのフィールドは、役に立たないフィールドでも削除しないでください。 これにより、Adobe Campaignデータベースで動作エラーが発生する可能性があります。
ソーススキーマは、 表示 属性 srcSchema ルート要素。 カスタムテーブルでAdobe Campaignを操作する場合に使用する必要があります。 この view="true" 属性は、データベース構造の更新ウィザードに対し、このスキーマを無視するよう指示します。 したがって、アプリケーションは、テーブル、その列およびそのインデックスを対応するスキーマと同期することはできません。
この属性が trueの場合、スキーマは、このテーブルのデータにアクセスする SQL クエリを生成する目的でのみ使用されます。
テーブルの更新ウィザードでテーブルを作成すると、テーブルと列の名前が、それぞれのスキーマと属性の名前に基づいて自動的に生成されます。 ただし、次の属性を入力することで、SQL 名の使用を強制できます。
例:
<element label="Individual" name="individual" sqltable="individual">
<key internal="true" name="id">
<keyfield xpath="@id"/>
</key>
<attribute name="id" type="long" length="32" />
<attribute name="lastName" type="string" length="100" sqlname="Last_Name"/>
<attribute name="firstName" type="string" length="100" sqlname="First_Name"/>
<attribute name="email" type="string" length="100"/>
<attribute name="mobile" type="string" length="100"/>
</element>
この例では、テーブルと列の名前が明示的に指定されていない場合、アプリケーションは CusIndividual テーブルの lastName および firstName 列の
スキーマでは、既存のテーブルの列の一部のみを入力できます。 未入力の列は、ユーザーがアクセスできなくなります。
クライアントコンソールからリストのレコードを並べ替える場合、インデックス付きのフィールドを並べ替えると、パフォーマンスが向上します。 スキーマでインデックスを宣言すると、次に示すように、コンソールに、列ラベルの左側にある並べ替え順矢印の下に赤い線が付いたインデックス付きフィールドが表示されます。
スキーマでは、インデックスは次のように定義されます。
<dbindex name="name_of_index" unique="true/false"
<keyfield xpath="xpath_1st_field"/
<keyfield xpath="xpath_2nd_field"/
...
</dbindex
そのため、一致するスキーマ内でカスタムテーブルの既存のインデックスを宣言することが重要です。
インデックスは、ソーススキーマの各キーおよびリンク宣言に対して暗黙的に宣言されます。 インデックス宣言は、 noDbIndex="true" 属性:
例:
<key internal="true" name="customer" noDbIndex="true">
<keyfield xpath="@customerId"/>
</key>