Conditions requises pour la table de base de données personnalisée

• Définissez une clé primaire ou un index à entrées uniques.

  Fonctions de l'environnement de transfert basées sur la clé. Afin d'éviter la consignation d'une quantité excessive de données dans la table STAGLOG, consignez-y uniquement la clé (clé primaire ou index à entrées uniques). Les utilitaires de transfert utilisent la clé pour la compression et pour la recherche des données à propager. En l'absence de cette clé, les utilitaires de transfert ne peuvent pas fonctionner.

  Les lignes contenues dans les tables activées pour le transfert doivent être identifiables de manière unique par au plus cinq colonnes : deux colonnes contenant des chaînes (longueur maximale : 254 caractères) et trois colonnes contenant des chiffres (longueur maximale : BIGINT). Si votre table personnalisée ne contient pas des lignes identifiables de manière unique respectant ces restrictions, vous devez modifier votre table de base de données personnalisée pour qu'elle le fasse.

• Il ne doit exister aucun cycle de contrainte d'intégrité référentielle (RI) dans les tables.

  L'environnement de transfert propage toujours la table parent avant la table enfant. S'il existe un cycle de contrainte RI, l'environnement de transfert ne peut pas distinguer les tables parent et enfant.

• Les noms de vos tables de base de données personnalisée doivent être en minuscule dans la table de base de données STAGLOG.

  Si les noms de vos tables de base de données personnalisées comprennent des lettres majuscules dans la table STAGLOG, le processus de transfert peut ne pas propager de données dans vos tables personnalisées.

• Les tables de base de données ne contiennent que des données de configuration.

  Dans un scénario concernant un magasin grand public, les données de configuration figurent sous le contrôle Administrateur de site (par exemple, catalogues et entrées de catalogues). Si une table contient des données opérationnelles, un client peut transformer cette même table en une base de données de production à la suite de la copie par l'Administrateur de site de la table dans les données prêtes pour la production. Cette copie peut provoquer un conflit de clés ou une violation de contrainte RI.

  Les tables de base de données ne doivent contenir aucune référence aux tables d'exploitation.

  Les tables devant être propagées ne doivent contenir aucune référence de clé externe aux clés primaires des tables d'exploitation. S'il existe une référence de ce type, les données ne peuvent pas être restaurées dans la base de données du produit si un client efface la clé primaire après l'exécution de l'utilitaire stagingcopy.

  Un déclencheur INSERT ne peut pas exister lors de l'insertion de deux tables dans la base de données de production.

  Pour deux tables couvertes par l'environnement de transfert (par exemple, R1 et R2), un déclencheur pour insérer des lignes dans R1 ou R2 ne peut pas exister lorsque vous insérez des données dans R2 et R1 dans la base de données de production. Le déclencheur INSERT crée une mise à jour dans les deux bases de données et engendre des incidents de clé.

• La restriction de suppression doit être utilisée avec précautions sur les tables de base de données personnalisées.

  La restriction de suppression annule les performances de l'utilitaire de nettoyage de base de données. Cette règle peut également provoquer des difficultés lors du nettoyage des données prêtes pour la production. Pour pouvoir effacer ces données, vous devez utiliser manuellement l'utilitaire de nettoyage de base de données avec l'option FORCE pour nettoyer les tables. Sinon, le nettoyage des données échoue.

Pour préparer l'environnement de transfert pour les tables personnalisées, reportez-vous à la section sur la configuration de l'environnement de transfert pour les tables personnalisées.