Administer > Stage server > Staging server utilities
Customized database table requirements
If you have customized the database schema by creating new tables, meet the several requirements to use the staging server.
- Define a primary key or a unique index.
The staging server functions based on the key.
To avoid logging excessive data in the STAGLOG table, log only the key (primary key or unique index). The stage utilities will use the key for compression and to find the data to be propagated. If there is no key, the stage utilities cannot work.
Rows in staging-enabled tables must be uniquely identifiable by at most five columns: Two columns containing strings (maximum length: 254 characters) and three columns containing numbers (maximum length: BIGINT). If the custom table does not have uniquely identifiable rows within these restrictions, modify the custom database table to meet these criteria
- A referential integrity (RI) constraint cycle cannot exist among the tables.
The staging server always propagates the parent table before the child table. If there is an RI constraint cycle, the staging server cannot distinguish between parent and child tables.
- The database tables only contain configuration data.
In a business-to-consumer scenario, configuration data is under Site Administrator control, such as catalogs and catalog entries. If a table contains operational data, a customer can change the same table in a production database after a Site Administrator has copied the table to the production-ready data. This causes a potential key conflict or an RI constraint violation.
- The database tables cannot contain any references to operation tables.
The tables to be propagated should not contain any foreign key references to the primary keys of operation tables. If there is such a reference, the data cannot be restored to the product database if a customer deletes the primary key after the stagingcopy.
- An insert trigger cannot exist when inserting two tables in the production database.
For any two tables covered by the staging server (for example, R1 and R2), a trigger to insert rows into R1 or R2 cannot exist when inserting into R2 and R1 in the production database. The insert trigger creates the update in both databases and generates key problems.
- The MEMBER table cannot have a unique index.
- Delete restrict on the customized database tables must be used with caution.
Delete restrict inhibits the Database Cleanup utility's performance. You can also experience difficulties when cleaning the production-ready data. Before you can clean the production-ready data, you have to manually use the Database Cleanup utility with the force option to clean the tables. Otherwise, cleaning the production-ready data will fail.
All foreign key relationships in the custom tables should specify ON DELETE CASCADE
To prepare the staging server for customized tables, refer to configuring the staging server for customized tables.