数据模型最佳实践

本文档概述了设计Adobe Campaign数据模型时的主要建议。

Adobe Campaign系统非常灵活，可以扩展到初始实施之外。 但是，尽管可能性是无限的，但做出明智决策并建立坚实的基础以开始设计数据模型至关重要。

要更好地了解Campaign内置表及其彼此的关系，请参阅 此部分.

阅读 此部分 以开始使用Campaign模式。

了解如何配置扩展模式以在 本页.

数据模型架构

Adobe Campaign是一款功能强大的跨渠道活动管理系统，可帮助您调整线上和线下策略以创建个性化的客户体验。

以客户为中心的方法

虽然大多数电子邮件服务提供商都在通过以列表为中心的方法与客户通信，但Adobe Campaign依赖关系数据库来利用客户及其属性的更广泛视图。

要访问每个表的说明，请转到 Admin > Configuration > Data schemas，从列表中选择资源，然后单击 Documentation 选项卡。

注意

Adobe Campaign允许构建 自定义收件人表. 但是，在大多数情况下，建议使用 收件人表 已经预建了其他表和功能。

Adobe Campaign数据

应将哪些数据发送到Adobe Campaign? 确定营销活动所需的数据至关重要。

注意

Adobe Campaign既不是data warehouse，也不是报告工具。 因此，请不要尝试将所有可能的客户及其关联信息导入Adobe Campaign，或导入仅用于构建报表的数据。

要决定是否需要某个属性在Adobe Campaign，请问自己是否属于以下类别之一：

  • 用于 分段
  • 用于 数据管理流程 （例如聚合计算）
  • 用于 个性化

如果不属于这些属性中的任何一个，您很可能在Adobe Campaign中不需要此属性。

数据类型选择

为确保系统的良好架构和性能，请按照以下最佳实践在Adobe Campaign中设置数据。

  • 在大表中，您可以插入字符串或数字字段，并将链接添加到引用表（处理值列表时）。
  • 的 expr 属性允许将架构属性定义为计算字段，而不是表中的物理集值。 这可以使用不同格式（例如，年龄和出生日期）访问信息，而无需存储这两个值。 这是避免复制字段的好方法。 例如，收件人表使用域的表达式，该表达式已在电子邮件字段中存在。
  • 但是，如果表达式计算比较复杂，则不建议使用 expr 属性（即时计算）可能会影响查询的性能。
  • 的 XML 类型是避免创建过多字段的好方法。 但是，当它使用数据库中的CLOB列时，它也会占用磁盘空间。 它还可能导致复杂的SQL查询，并可能影响性能。
  • 表示 字符串 字段时，应始终使用列进行定义。 默认情况下，Adobe Campaign中的最大长度为16K，但是如果您已经知道字段的大小不会超过较短的长度，则Adobe建议将字段保持较短。
  • 如果您确定源系统中的字段大小被高估，并且无法达到，则可以将Adobe Campaign中的字段短于源系统中的字段。 这可能表示Adobe Campaign中的字符串较短或整数较小。

字段选择

如果字段具有定位或个性化目的，则需要将其存储在表中。 换言之，如果某个字段未用于发送个性化电子邮件或用作查询中的标准，则将不必占用磁盘空间。

键选择

除 autouuid 和 奥托普 默认情况下，在大多数表中定义，您应当考虑添加一些逻辑密钥或业务密钥（帐号、客户端号等）。 它稍后可用于导入/协调或数据包。 有关此内容的更多信息，请参阅 标识符.

高效的键对性能至关重要。 通过Snowflake，您可以插入数字或基于字符串的数据类型作为表的键。

注意

的 autouuid 属性仅适用于 企业(FFDA)部署.

标识符

Adobe Campaign资源具有三个标识符，并且可以添加其他标识符。

下表介绍了这些标识符及其用途。

标识符 说明 最佳实践
Id
  • ID是Adobe Campaign表的物理主键。 对于内置表，它是通用唯一ID(UUID)
  • 此标识符必须唯一。
  • UUID可在架构定义中显示。
  • 自动生成的标识符不应用作工作流或包定义中的引用。
  • 表中的id为UUID，不应更改此类型。
名称（或内部名称）
  • 此信息是表中记录的唯一标识符。 此值可手动更新，通常使用生成的名称。
  • 此标识符在部署到其他Adobe Campaign实例时会保留其值，它不应为空。
  • 如果要将Adobe Campaign生成的对象从环境部署到另一个环境，请重命名该记录名称。
  • 当对象具有命名空间属性(模式 例如)，此通用命名空间将用于所有创建的自定义对象。 不应使用某些保留的命名空间： nms, xtk​等。 请注意，某些命名空间仅是内部命名空间。 了解详情。
  • 当对象没有任何命名空间(工作流 或 投放 例如)，此命名空间概念将作为内部名称对象的前缀添加： namespaceMyObjectName.
  • 请勿使用特殊字符，如空格“”、半列“：”或连字符“ — ”。 所有这些字符都将替换为下划线“_”（允许的字符）。 例如，“abc-def”和“abc:def”将存储为“abc_def”并相互覆盖。
标签
  • 标签是Adobe Campaign中对象或记录的业务标识符。
  • 此对象允许使用空格和特殊字符。
  • 它不保证记录的唯一性。
  • 建议确定对象标签的结构。
  • 这是用于为Adobe Campaign用户标识记录或对象的最易用的解决方案。

在 企业(FFDA)部署，则Adobe Campaign主键是自动为所有内置表生成的UUID。 UUID也可用于自定义表。 了解详情

即使ID数量是无限的，您也应该考虑数据库的大小，以确保获得最佳性能。 要防止出现任何问题，请确保调整实例清除设置。 有关更多信息，请参阅此章节。

自定义内部键

在Adobe Campaign中创建的每个表都需要使用主键。

大多数组织正在从外部系统导入记录。 虽然Recipient表的物理键是“id”属性，但也可以确定自定义键。

此自定义键值是外部系统馈送Adobe Campaign时的实际记录主键。

创建自定义表时，有两个选项：

  • 自动生成键(id)和内部键（自定义）的组合。 如果您的系统键是复合键或不是整数，则此选项很有趣。 通过Snowflake，整数或基于字符串的键将在大表中提供更高的性能，并与其他表连接。
  • 使用主键作为外部系统主键。 此解决方案通常比较首选，因为它通过不同系统之间一致的键简化了数据导入和导出的方法。 奥图uid 如果键名为“id”，且应使用外部值填充（非自动生成），则应禁用该键。
注意
  • 在工作流中，不应使用autouuid作为引用。
  • 的 autouuid 属性仅适用于 企业(FFDA)部署.

请注意大型表格上的“自己”完整性。 如果删除具有“自有”完整性的大表的记录，可能会阻止实例。 表已锁定，删除内容逐个删除。 因此，最好在具有大量子的子表格上使用“中性”完整性。

将链接声明为外部连接不利于性能。 零ID记录模拟外部连接功能。 在 企业(FFDA)部署，则在链接使用 autouuid.

虽然可以连接工作流中的任何表，但Adobe建议直接在数据结构定义中定义资源之间的通用链接。

链接的定义应与表中的实际数据保持一致。 错误的定义可能会影响通过链接检索到的数据，例如意外复制记录。

使用表名称始终如一地命名链接：链接名称应有助于了解远程表格的内容。

请勿将链接命名为后缀为“id”。 例如，将其命名为“transaction”，而不是“transactionId”。

默认情况下，Adobe Campaign将使用外部表的主键创建链接。 为了更清楚地了解，最好在链接定义中显式定义连接。

基数

在设计链接时，请确保在声明1-1关系后目标记录是唯一的。 否则，当只需要一条记录时，连接可能会返回多条记录。 当“查询返回的行数多于预期值”时，这会在投放准备期间导致错误。 将链接名称设置为与目标架构相同的名称。

在(1)侧的架构中定义具有基数(1-N)的链接。 例如，应在事务架构中定义“收件人(1)-(N)事务”关系。

请注意，链接的反向基数默认为(N)。 可以通过向链接定义添加revCardinality='single'属性来定义链接(1-1)。

如果用户看不到反向链接，则可以使用链接定义revLink='隐藏该链接​无'。 这的一个好用例是，例如，定义从收件人到完成的最后一个交易的链接。 您只需查看从收件人到最后一个交易的链接，而无需从交易表中查看反向链接。

执行外部连接(1-0.1)的链接应当谨慎使用，因为它将影响系统性能。

数据保留

Adobe Campaign既不是data warehouse，也不是报告工具。 因此，为确保Adobe Campaign解决方案的良好性能，数据库增长应保持可控。 要实现此目的，请遵循以下一些最佳实践，这可能会有所帮助。

关于保留时间，Campaign 中的内置日志表具有预设的保留期，通常将其数据存储限制为 6 个月或更短时间。

以下是内置表的默认保留时间值。请注意，保留时间配置由 Adobe 技术管理员在实施期间设置，每项实施的值可能因客户要求而异。

  • 整合跟踪：1 年
  • 投放日志：6 个月
  • 跟踪日志：1 年
  • 已删除的投放：1 周
  • 被拒绝的导入内容：6 个月
  • 访客用户档案：1 个月
  • 优惠建议：1 年
  • 事件：1 个月
  • 事件处理统计信息：1 年
  • 存档事件：1 年
  • 已忽略的渠道事件：1 个月
注意

自定义表不会使用标准清理过程清除。 虽然在第1天可能不需要执行此操作，但请不要忘记为自定义表构建清除流程，因为这可能会导致性能挑战。

在Adobe Campaign中，有几种解决方案可最大程度地减少对记录的需求：

  • 在Adobe Campaign以外的data warehouse中导出数据。
  • 生成聚合值，在满足您的营销实践需求的同时，使用较少的空间。 例如，您不需要Adobe Campaign中具有完整的客户交易历史记录即可跟踪上次购买。

您可以在架构中声明“deleteStatus”属性。 将记录标记为已删除，然后在清理任务中推迟删除更为有效。

作为受管Cloud Services用户，请联系Adobe顾问或技术管理员，以了解有关保留率的更多信息，或者您是否需要为自定义表设置保留率。

性能

为确保在任何时间都获得更好的性能，请遵循以下最佳实践。

一般建议

  • 避免在查询中使用“包含”等操作。 如果您知道预期内容并希望过滤对象，请使用“等于”或其他特定过滤器运算符应用相同的条件。
  • 尝试确保在工作时间完成导入和导出等过程。
  • 确保有所有日常活动的时间表，并遵守时间表。
  • 如果一个或几个日常进程失败，并且如果必须在同一天运行它，请确保在启动手动进程时没有运行冲突的进程，因为这可能影响系统性能。
  • 确保在导入过程或执行任何手动过程期间均未运行任何每日营销活动。
  • 使用一个或多个引用表，而不是在每个行中复制字段。 使用键/值对时，最好选择数字键。
  • 短字符串仍可接受。 如果外部系统中已有引用表，则重用该表将有助于与Adobe Campaign进行数据集成。

一对多关系

  • 数据设计会影响可用性和功能。 如果您设计的数据模型具有许多一对多关系，则用户在应用程序中构建有意义的逻辑会比较困难。 对于非技术营销人员而言，一对多过滤逻辑可能很难正确构建和理解。
  • 将所有基本字段都放在一个表中是件好事，因为这样用户就可以更轻松地构建查询。 有时，如果在表中复制某些字段以避免连接，则在性能上也会很好。
  • 某些内置功能将无法引用一对多关系，例如选件加权公式和投放。

大表

Adobe Campaign依赖第三方数据库引擎。 根据提供商的不同，为较大的表优化性能可能需要特定的设计。

以下是在使用大型表和复杂连接设计数据模型时应遵循的一些常见最佳实践。

  • 使用其他自定义收件人表时，请确保每个投放映射都有一个专用的日志表。
  • 减少列数，特别是通过标识未使用的列数。
  • 通过避免复杂的连接（如多个条件和/或多个列上的连接）来优化数据模型关系。
  • 对于连接键，您可以使用基于数字或字符串的值。
  • 尽量减少日志保留的深度。 如果需要更深的历史记录，您可以聚合计算和/或处理自定义日志表以存储更大的历史记录。

表的大小

表大小是记录数和每个记录列数的组合。 这两种方法都会影响查询的性能。

  • A 小尺寸 表与“提交”表类似。
  • A 中等大小 表与收件人表的大小相同。 每个客户有一个记录。
  • A 大尺寸 表与“广泛”日志表类似。 每个客户有许多记录。
    例如，如果您的数据库包含1000万个收件人，则“广泛”日志表包含大约1亿到2亿条消息，而“投放”表包含几千条记录。

行数也会影响性能。 Adobe Campaign数据库并非用于存储未主动用于定位或个性化目的的历史数据 — 这是一个操作数据库。

要防止与行数高相关的任何性能问题，请仅在数据库中保留必要的记录。 任何其他记录都应导出到第三方data warehouse，并从Adobe Campaign操作数据库中删除。

以下是有关表大小的一些最佳实践：

  • 设计字段较少且数字数据较多的大型表。
  • 请勿使用大数类型的列来存储小数字，如布尔值。
  • 从表定义中删除未使用的列。
  • 请勿在Adobe Campaign数据库中保留历史数据或不活动数据（导出和清理）。

在此页面上