カスタマイズ・データベース・テーブルの要件
新規テーブルを作成することによってデータベース・スキーマをカスタマイズした場合に、ステージング・サーバーを使用するには以下の要件を満たしている必要があります。
- 基本キーまたは固有索引を定義している必要があること。
ステージング・サーバー機能はこのキーに基づいています。 STAGLOG テーブルに過剰なデータをロギングしないようにするには、キー (基本キーまたは固有索引) だけをログに記録します。 ステージ・ユーティリティーは、圧縮用および伝搬データの検索用にこのキーを使用します。 このキーがないと、ステージ・ユーティリティーは機能しません。
- テーブル相互間に参照保全 (RI) 制約サイクルが存在できないこと。
ステージング・サーバーは、常に子テーブルの前に親テーブルを伝搬します。 RI 制約サイクルがあると、ステージング・サーバーは親と子テーブルを区別できません。
- データベース・テーブルに構成データだけが入っていること。
ビジネス対顧客のシナリオでは、構成データは、カタログやカタログ・エントリーなどのサイト管理者の制御の下に置かれます。 テーブルに操作データが含まれている場合は、
サイト管理者がステージング・データベースにテーブルをコピーした後で、顧客は実動データベース中の同じテーブルを変更できます。 これによって、キーの矛盾や RI 制約違反が起こることがあります。
- データベース・テーブルに、操作テーブルへの参照を入れることはできません。
伝搬するテーブルには、操作テーブルの基本キーへの外部キー参照を入れてはいけません。 こうした参照があると、顧客がステージ・コピーの後で基本キーを削除した場合にデータを商品データベースに復元できなくなります。
実動データベースに 2 つのテーブルを挿入する時には、挿入トリガーがあってはならないこと。
ステージング・サーバーでカバーされる 2 つのテーブル (たとえば、R1 および R2) について、
実動データベースの、R1 および R2 に挿入する時に、R1 または R2 に行を挿入するトリガーがあってはなりません。 挿入トリガーは、両方のデータベースに更新を作成し、キーの問題を生成します。
- MEMBER テーブルには、固有索引は含められないこと。
- カスタマイズ・データベース・テーブルの削除制限の使用には注意が必要なこと。
削除制限は、データベース・クリーンアップ・ユーティリティーのパフォーマンスを抑制します。 また、ステージング・データベースを空にすることが困難になる可能性があります。 ステージング・データベースを空にする前に、テーブルを空にする強制オプション付きでデータベース・クリーンアップ・ユーティリティー・コマンドを手動で使用しなければなりません。 そうでない場合には、ステージング・データベースの消去は失敗することになります。
カスタマイズ・テーブルのステージング・サーバーを準備するには、カスタマイズ・テーブルのステージング・サーバーの構成 を参照します。