Cet article détaille mes meilleures pratiques pour créer le modèle de données Adobe Campaign Classic (v6 ou v7).

Introduction

Adobe Campaign repose sur des bases de données externes. Elle n’a aucune limite sur la taille des tableaux. Pour optimiser les performances, les tableaux volumineux doivent avoir une conception spécifique. Cet article explique comment optimiser la conception de base de données pour des volumes plus volumineux.

Taille des tableaux

  • Un tableau de petite taille est semblable à la table de diffusion.
  • Un tableau de taille moyenne est pareil au tableau du destinataire. Il possède un enregistrement par client.
  • Un tableau de grande taille est semblable au tableau de journal. Il possède de nombreux enregistrements par client.

Par exemple, si votre base de données contient 10 millions de destinataires, la table de journal contient environ 100 à 200 millions de messages, et la table de diffusion contient des milliers d’enregistrements.

Remarque :

Il est recommandé de concevoir des tableaux volumineux avec moins de champs et des données numériques.

Exemple

Dans cet exemple, les transactions et les tableaux d’élément de transaction sont importants : plus de 10 millions.

Les tableaux de produit et de stockage sont plus petits : moins de 10 000.

Le libellé et la référence du produit ont été placés dans le tableau du produit.

Le tableau Articles de transaction comporte uniquement un lien vers le tableau produit, qui est numérique.

image2014-1-14_10-40-22

Choix des types de données

Un tableau volumineux doit avoir essentiellement des champs numériques et contient des liens vers des tableaux de référence.

Vous pouvez utiliser des attributs « expr » pour éviter les doublons de champs. Par exemple, le tableau destinataire utilise une expression pour le domaine, qui est déjà présente dans le champ Courriel.

Le type « XML » est judicieux pour éviter de créer trop de champs. Toutefois, l’espace disque est également utilisé comme espace disque dans la base de données.

Choix des champs

Les pilotes nécessaires pour stocker un champ doivent être stockés dans un tableau : le ciblage de l’objectif ou la personnalisation. En d’autres termes, si un champ n’est pas utilisé pour envoyer un courrier électronique personnalisé ou utilisé comme critère dans une requête, vous devez considérer que ce champ est inutile et occupe l’espace disque pour rien. 


Gardez à l’esprit que FDA (accès aux données fédéré, une fonctionnalité optionnelle qui permet d’accéder aux données externes) couvre la nécessité d’ajouter un champ à la volée durant un processus de campagne. Vous n’avez pas besoin d’importer tout si vous possédez FDA.

Choix des clés

Outre le « Autopk » défini par défaut dans la plupart des tableaux, vous devez envisager d’ajouter des clés logiques ou d’entreprise (numéro de compte, numéro de client, etc.). Il peut être utilisé ultérieurement pour l’importation/la reconnexion ou les packages de données.

Des clés efficaces sont essentielles pour les performances. Les types de données numériques doivent toujours être préférés en tant que clés pour les tableaux.

Pour la base de données SQLServer, vous pouvez envisager d’utiliser l'« Index aggloméré » si les performances sont nécessaires. Etant donné qu’Adobe ne se gère pas, vous devez le créer dans SQL. 

Index

Les index sont essentiels pour les performances. Lorsque vous déclarez une clé dans le schéma, Adobe crée automatiquement un index sur les champs de la clé. Vous pouvez également déclarer d’autres index pour les requêtes qui n’utilisent pas la clé.

Les index doivent être limités en taille et en nombre, car cela affecte les performances lors de l’insertion de données.

Liens et cardinalité

Lorsque vous créez un lien, assurez-vous que l’enregistrement de cible est unique lorsque des relations 1-1 ont été effectuées. Dans le cas contraire, la jointure risque de renvoyer plusieurs enregistrements lorsqu’un seul est attendu. Ceci entraîne des erreurs lors de la préparation de la diffusion lorsque la requête renvoie plus de lignes que prévu. Définissez le nom du lien sur le même nom que le schéma cible.

Faites attention à la cardinalité « propre » sur des tableaux volumineux. La suppression d’enregistrements comportant des tableaux de grande taille dans la cardinalité « propre » peut interrompre l’occurrence. Le tableau est verrouillé et les suppressions sont effectuées une par une. Il est donc préférable d’utiliser la cardinalité « neutre » sur les tableaux enfant comportant des volumes volumineux.

Le fait de déclarer un lien comme une jointure externe n’est pas utile pour les performances. L’enregistrement d’identifiant zéro émule la fonctionnalité de jointure externe. Il n’est pas nécessaire de déclarer des références externes si le lien utilise la classe autopk.

Partionnement

Le partitionnement au niveau de la base de données peut être une solution pour optimiser les requêtes sur certains tableaux avec des volumes volumineux. Les stratégies diffèrent des objectifs du tableau.

  • Pour les échanges de réponses ou de rapports, les journaux et les transactions de la partition sont importants par semaine ou par mois pour optimiser l’accès aux données les plus récentes.
  • Pour le marketing distribué, partitionnez la table de destinataires par région ou par agence afin d’optimiser l’accès aux données locales.

Tablespaces dédiés

L’attribut Qatar dans le schéma vous permet de spécifier un tablespace dédié pour un tableau.

L’assistant d’installation vous permet de stocker des objets par type (données, temporaires et index).

Les tablespaces dédiés sont mieux adaptés au partitionnement, aux règles de sécurité et à l’administration fluide et souple, à l’optimisation et aux performances.

Relations One-to-many

La conception de données affecte l’utilisation et la fonctionnalité. Si vous concevez votre modèle de données avec de nombreuses relations one-to-many, il est plus difficile pour les utilisateurs de créer une logique significative dans l’application. La relation logique de filtrage peut être difficile à comprendre et construire correctement pour les spécialistes du marketing sans connaissance informatique. 

Il est recommandé d’avoir tous les champs essentiels dans un tableau, car cela facilite la création de requêtes. Il peut également s’avérer utile de dupliquer certains champs dans des tableaux si cela peut éviter une jointure. 

Certaines fonctionnalités intégrées ne pourront pas faire référence à des relations one-to-many, par exemple, la substitution d’offres et les diffusions. 

Tâche de nettoyage

Vous pouvez déclarer l’attribut « deleteStatus » dans un schéma. Il est plus efficace de marquer l’enregistrement comme étant supprimé, puis de le retarder dans la tâche de nettoyage.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne