v7

数据模型最佳实践

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

要更好地了解Campaign内置表及其交互，请参阅 本节 部分。

已阅读 本文档 以开始使用Campaign模式。 了解如何配置扩展模式以扩展Adobe Campaign数据库的概念数据模型 本文档.

概述

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

本文档提供了常见用例和最佳实践，以了解如何正确构建Adobe Campaign工具。

数据模型架构

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

以客户为中心的做法

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

下图显示了这种以客户为中心的方法。 此 收件人 灰色表格表示构建所有内容的主客户表格：

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

Adobe Campaign默认数据模型在中介绍 本文档.

Adobe Campaign的数据

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

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

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

如果不属于任何此类属性，则在Adobe Campaign中很可能不需要此属性。

数据类型选择

要确保良好的体系结构和系统性能，请遵循以下最佳实践在Adobe Campaign中设置数据。

• 大型表格通常应该具有数值字段，并包含引用表格的链接（在使用值列表时）。
• 此 表达式 属性允许将模式属性定义为计算字段，而不是表中的物理集值。 这样，就可以以不同格式（例如年龄和出生日期）访问信息，而无需存储这两个值。 这是避免字段重复的好方法。 例如，收件人表使用域表达式，该表达式已存在于电子邮件字段中。
• 但是，当表达式计算复杂时，建议不要使用 表达式 属性，因为动态计算可能会影响查询的性能。
• 此 XML 键入是避免创建太多字段的好方法。 但是，它也会占用磁盘空间，因为它使用数据库中的CLOB列。 它还会导致复杂的SQL查询，并可能影响性能。
• 的长度 字符串 字段应始终使用列进行定义。 默认情况下，Adobe Campaign中的最大长度为255，但Adobe建议，如果您已经知道大小不会超过更短的长度，请缩短该字段。
• 如果您确定源系统中的字段大小被高估并且无法到达，则可以接受Adobe Campaign中的字段比源系统中的字段更短。 这可能意味着Adobe Campaign中的字符串长度更短，整数更小。

字段选择

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

对于混合实例和内部部署实例，FDA（联合数据访问，允许访问外部数据的一项可选功能）涵盖了在营销活动过程中需要“实时”添加字段的需求。 如果您拥有联合数据访问(FDA)，则无需导入所有内容。 有关此内容的更多信息，请参阅 关于联合数据访问.

键选择

除了 autopk 在大多数表中默认定义时，应考虑添加一些逻辑或业务密钥（帐号、客户机号等）。 以后可用于导入/协调或数据包。 有关此内容的更多信息，请参阅 标识符.

高效的密钥对于性能至关重要。 数值数据类型应始终作为表的键首选。

对于SQLServer数据库，如果需要性能，可以考虑使用“聚簇索引”。 由于Adobe不处理此问题，因此您需要在SQL中创建它。

专用表空间

使用方案中的“表空间”属性可以为表指定专用表空间。

安装向导允许您按类型（数据、临时和索引）存储对象。

专用表空间更适合分区、安全规则，并允许灵活流畅的管理、更好的优化和性能。

标识符

Adobe Campaign资源有三个标识符，可以添加额外的标识符。

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

自定义内部键

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

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

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

当开箱即用表同时具有autopk和内部键时，内部键将被设置为物理数据库表中的唯一索引。

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

• 自动生成的键(id)和内部键（自定义）的组合。 如果系统键是复合键或不是整数，则此选项很有趣。 整数将在大表中提供更高的性能，并可与其他表连接。
• 使用主键作为外部系统主键。 此解决方案通常为首选方案，因为它简化了导入和导出数据的方法，并在不同系统之间使用了一致的密钥。 如果键名为“id”，并且应使用外部值填充（非自动生成），则应禁用Autopk。

序列

Adobe Campaign主键是为所有现成表格自动生成的id，对于自定义表格可以相同。 有关更多信息，请参阅此章节。

此值获取自所谓的 序列，是用于生成编号规则的数据库对象。

序列有两种类型：

• 已共享：多个表将从同一序列中选择其id。 这意味着如果一个表使用了ID 'X'，则共享相同序列的其他表都不会有该ID 'X'的记录。 XtkNewId 是Adobe Campaign中可用的默认共享序列。
• 专用：只有一个表从序列中选择其id。 序列名称通常包含表名。

因此，如果客户每年发送60亿封电子邮件，并且日志的保留期为180天，那么他们的id将在4个月内用完。 要防止此类挑战，请确保根据卷设置清除设置。 有关更多信息，请参阅此章节。

在Adobe Campaign中创建一个主键为autoPK的自定义表时，应将自定义专用序列系统地与该表关联。

默认情况下，自定义序列的值介于+1,000到+2.1BB之间。 从技术上讲，通过启用负ID可以获得完整的4BB范围。 应谨慎使用此属性，当从负数交叉到正数时，将丢失一个id：在生成的SQL查询中，Adobe Campaign通常会忽略记录0。

有关序列消耗的更多信息，请观看 此视频.

索引

索引对于性能至关重要。 在架构中声明键时，Adobe将自动在键的字段上创建索引。 您还可以为不使用键的查询声明更多索引。

Adobe建议定义其他索引，因为这可以提高性能。

但是，请牢记以下事项：

• 索引使用方式与您的访问模式绑定。 优化索引通常是数据库设计中的一个关键部分，必须由专家来处理。 添加索引通常是附加在数据库维护上的迭代工作流。 随着时间的推移，该过程会逐步完成，以解决发生时的性能问题。
• 索引会增加表的整体大小（用于存储索引本身）。
• 在列上添加索引可以提高数据读取访问(SELECT)的性能，但是会降低数据写入访问(UPDATE)的性能。
• 由于这会影响数据插入期间的性能，因此应该限制索引的大小和数量。
• 必要时不要添加索引。 确保它是必需的，并提高了查询的整体性能（测试和学习）。
• 一般而言，如果您知道查询不会返回超过10%的记录，索引将很有效。
• 仔细选择需要定义的索引。
• 请勿从现成表格中删除本机索引。

示例

管理索引可能会变得非常复杂，因此了解索引的工作方式非常重要。 为了说明这种复杂性，让我们举一个基本示例，例如通过筛选名字和姓氏来搜索收件人。 操作步骤：

1. 转到列出数据库中所有收件人的文件夹。 有关此内容的更多信息，请参阅 管理用户档案.

2. 右键单击 First name 字段。

3. 选择 Filter on this field。

   

4. 对重复此操作 Last name 字段。

屏幕上会添加两个相应的过滤器。

您现在可以对以下内容执行搜索过滤 First name 和 Last name 字段的过滤条件。

现在，为了加快对这些过滤器的搜索，您可以添加索引。 但应使用哪些索引？

下表显示了在何种情况下根据第一列中显示的访问模式使用或不使用下述三个索引。

链接和基数

链接

请注意大型表上的“自身”完整性。 删除具有“拥有”完整性的宽表的记录可以停止实例。 表格被锁定，删除操作逐一进行。 因此，最好在具有大卷的子表上使用“中立”完整性。

将链接声明为外部连接对性能不利。 零ID记录模拟外部连接功能。 如果链接使用autopk，则无需声明外部连接。

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

应根据表中的实际数据来定义链接。 错误定义可能会影响通过链接检索的数据，例如，意外地复制记录。

以与表名称一致的形式命名您的链接：链接名称应有助于了解远程表是什么。

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

默认情况下，Adobe Campaign将使用外部表的主键创建一个链接。 为清楚起见，最好在链接定义中明确定义连接。

索引将被添加到链接中使用的属性。

“创建者”和“上次修改者”链接存在于许多表中。 如果业务未使用此信息，则可以使用链接上的属性noDbIndex禁用索引。

基数

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

在(1)侧的架构中定义具有基数(1-N)的链接。 例如，应在事务模式中定义关系Recipient (1) - (N) Transaction。

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

如果用户应该看不到反向链接，可以使用链接定义revLink='来隐藏它​无'. 一个很好的用例是定义从收件人到完成的最后一笔交易的链接。 您只需要查看从收件人到最后一个交易的链接，并且不需要从交易表中显示反向链接。

执行外部联接(1-0…1)的链接应谨慎使用，因为它会影响系统性能。

数据保留 — 清理和清除

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

默认情况下，Adobe Campaign投放和跟踪日志的保留时间为180天。 将运行清理过程以删除任何早于该时间的日志。

• 如果您希望保留日志更长，则应根据数据库大小和发送的消息量仔细做出此决定。 请注意，Adobe Campaign序列是一个32位整数。
• 建议这些表中一次记录不要超过10亿条（大约占可用的21.4亿id的50%），以限制占用所有可用id的风险。 这将要求某些客户将保留期限降低到180天以下。

要了解有关数据保留的更多信息，请参阅 Campaign隐私和安全准则.

了解有关Campaign数据库清理工作流的更多信息 在此部分中.

有几个解决方案可以最大程度地降低Adobe Campaign中对记录的需求：

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

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

性能

为了确保随时获得更好的性能，请遵循以下最佳实践。

一般建议

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

一对多关系

• 数据设计会影响可用性和功能。 如果您设计的数据模型具有大量一对多关系，则会使用户更难以在应用程序中构建有意义的逻辑。 对于非技术性营销人员，可能很难正确构建和理解一对多过滤器逻辑。
• 将所有基本字段放在一个表中是件好事，因为这样用户更容易构建查询。 有时，如果可以避免联接，则跨表复制某些字段对性能也有好处。
• 某些内置功能将无法引用一对多关系，例如优惠权重公式和投放。

大型表

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

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

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

表的大小

表大小是记录数和每条记录列数的组合。 两者都会影响查询的性能。

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

在PostgreSQL上，行不应超过8 KB才能避免 TOAST 机制。 因此，应尽量减少列数和每行大小，以保持系统的最佳性能（内存和CPU）。

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

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

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

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

示例如下：

在此示例中：

• 此 交易 和 交易记录物料 表格很大：超过1000万。
• 此 产品 和 存储 表更小：少于10,000。
• 产品标签和参考已放在 产品 表格。
• 此 交易记录物料 表仅具有指向以下内容的链接： 产品 表格，这是数字的。