数据模型最佳实践 data-model-best-practices
本文档概述了设计Adobe Campaign数据模型时的主要建议。
要更好地了解Campaign内置表及其交互，请参阅此部分部分。
阅读此文档以开始使用Campaign架构。 在本文档中了解如何配置扩展模式以扩展Adobe Campaign数据库的概念数据模型。
概述 overview
Adobe Campaign系统非常灵活，可以在初始实施之后扩展。 但是，尽管可能性是无限的，但做出明智决策并奠定坚实的基础来开始设计数据模型至关重要。
本文档提供了常见用例和最佳实践，以了解如何正确构建Adobe Campaign工具。
数据模型架构 data-model-architecture
Adobe Campaign是一款功能强大的跨渠道活动管理系统，可帮助您调整线上和线下策略以创建个性化的客户体验。
以客户为中心的做法 customer-centric-approach
虽然大多数电子邮件服务提供商都通过以列表为中心的方法与客户通信，但Adobe Campaign依靠关系数据库以更广泛地了解客户及其属性。
此以客户为中心的方法如下图所示。 灰色的 Recipient 表表示正在生成所有内容的主客户表：
要访问每个表的说明，请转到 Admin > Configuration > Data schemas，从列表中选择资源，然后单击 Documentation 选项卡。
Adobe Campaign默认数据模型在此文档中显示。
Adobe Campaign的数据 data-for-campaign
应将哪些数据发送到Adobe Campaign？ 确定营销活动所需的数据至关重要。
要决定是否需要在Adobe Campaign中使用某个属性，请问自己该属性是否属于以下类别之一：
- 用于 分段 的属性
- 用于 数据管理进程 的属性（例如，聚合计算）
- 用于 个性化 的属性
如果不属于上述任何一种，您很可能不会在Adobe Campaign中需要此属性。
数据类型选择 data-types
要确保良好的体系结构和系统性能，请遵循以下最佳实践在Adobe Campaign中设置数据。
- 大型表通常应该具有数值字段并包含引用表的链接（在使用值列表时）。
- expr 属性允许将架构属性定义为计算字段而不是表中的物理集值。 这样，即可以不同格式（例如年龄和出生日期）访问信息，而无需存储这两个值。 这是避免字段重复的好方法。 例如，收件人表使用域表达式，该表达式已存在于电子邮件字段中。
- 但是，当表达式计算复杂时，不建议使用 expr 属性，因为动态计算可能会影响查询的性能。
- XML 类型是避免创建过多字段的好方法。 但是，它也会占用磁盘空间，因为它使用数据库中的CLOB列。 它还可能导致复杂的SQL查询，并可能影响性能。
- 字符串 字段的长度应始终使用列定义。 默认情况下，Adobe Campaign中的最大长度为255，但是Adobe建议，如果您已经知道字段大小不会超过更短的长度，则保持该字段更短。
- 如果您确定源系统中的字段大小被高估而无法达到，则可以接受Adobe Campaign中的字段比源系统中的字段更短。 这可能意味着Adobe Campaign中的字符串长度更短，整数更小。
字段选择 choice-of-fields
如果某个字段具有定位或个性化目的，则需要将其存储在表中。 换言之，如果字段未用于发送个性化电子邮件或未用作查询中的标准，则它占用磁盘空间而无用。
对于混合实例和内部部署实例，FDA（联合数据访问，允许访问外部数据的可选功能）涵盖在营销活动过程中“实时”添加字段的需求。 如果您拥有联合数据访问(FDA)，则无需导入所有内容。 有关此内容的详细信息，请参阅关于联合数据访问。
键选择 choice-of-keys
除了大多数表中默认定义的 autopk 之外，您还应考虑添加一些逻辑或业务密钥（帐号、客户端编号等）。 以后可用于导入/协调或数据包。 有关详细信息，请参阅标识符。
高效的密钥对于性能至关重要。 数值数据类型应始终作为表的键首选。
对于SQLServer数据库，如果需要性能，可以考虑使用“聚簇索引”。 由于Adobe不处理此问题，因此您需要在SQL中创建它。
专用表空间 dedicated-tablespaces
使用方案中的“表空间”属性可以为表指定专用表空间。
安装助手允许您按类型（数据、临时和索引）存储对象。
专用表空间更适合分区、安全规则，并允许灵活流畅的管理、更好的优化和性能。
标识符 identifiers
Adobe Campaign资源具有三个标识符，可以添加额外的标识符。
下表描述了这些标识符及其用途。
- ID是Adobe Campaign表的物理主键。 对于开箱即用的表，它是从序列生成的32位数字
- 此标识符通常特定于特定的Adobe Campaign实例。
- 自动生成的ID可在架构定义中可见。 搜索 autopk="true" 属性。
- 不应在工作流或包定义中将自动生成的标识符用作引用。
- 不应假设id将始终为递增数。
- 现成表格中的ID是32位数字，不应更改此类型。 此数字取自部分中包含的具有相同名称的“序列”。
- 此信息是表中记录的唯一标识符。 此值可手动更新，通常使用生成的名称。
- 当此标识符部署在Adobe Campaign的其他实例中时，会保留其值，并且它不应为空。
- 如果打算将对象从一个环境部署到另一个环境，请重命名Adobe Campaign生成的记录名称。
- 当对象具有命名空间属性（例如 架构）时，此公用命名空间将在创建的所有自定义对象中使用。 不应使用某些保留的命名空间： nms、xtk、nl、ncl、crm、xxl。
- 当对象没有任何命名空间（例如 工作流 或 投放）时，此命名空间概念将被添加为内部名称对象的前缀： namespaceMyObjectName。
- 请勿使用空格“ ”、分号“：”或连字符“ — ”等特殊字符。 所有这些字符都将替换为下划线“_”（允许的字符）。 例如，“abc-def”和“abc：def”将存储为“abc_def”并相互覆盖。
- 标签是Adobe Campaign中对象或记录的业务标识符。
- 此对象允许使用空格和特殊字符。
- 它不能保证记录的唯一性。
- 建议确定对象标签的结构。
- 这是用于为Adobe Campaign用户标识记录或对象的最用户友好的解决方案。
自定义内部键 custom-internal-keys
在Adobe Campaign中创建的每个表都需要主键。
大多数组织正在从外部系统导入记录。 虽然收件人表的物理键是“id”属性，但也可以确定自定义键。
此自定义键是外部系统中馈送Adobe Campaign的实际记录主键。
当开箱即用的表同时具有自动执行密钥和内部密钥时，内部密钥将被设置为物理数据库表中的唯一索引。
创建自定义表时，您有两个选项：
- 自动生成的键(id)和内部键（自定义）的组合。 如果系统键是复合键或不是整数，则此选项很有趣。 整数将在大表中提供更高的性能，并可与其他表连接。
- 使用主键作为外部系统主键。 此解决方案通常是首选的，因为它简化了导入和导出数据的方法，在不同的系统之间使用了一致的密钥。 如果键名为“id”，并且应使用外部值填充（非自动生成），则应禁用Autopk。
序列 sequences
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：Adobe Campaign通常会在生成的SQL查询中忽略记录0。
有关序列消耗的详细信息，请观看此视频。
索引 indexes
索引对于性能至关重要。 在架构中声明键时，Adobe将自动为该键的字段创建索引。 您还可以为不使用键的查询声明更多索引。
Adobe建议定义其他索引，因为它可能会提高性能。
但是，请牢记以下内容：
- 索引使用情况与您的访问模式相关联。 优化索引通常是数据库设计中的一个关键部分，必须由专家来处理。 添加索引通常是附加于数据库维护的迭代工作流。 此过程会随着时间的推移逐步完成，以解决发生时的性能问题。
- 索引会增加表的整体大小（用于存储索引本身）。
- 在列上添加索引可以提高数据读取访问(SELECT)的性能，但会降低数据写入访问(UPDATE)的性能。
- 由于这会影响数据插入期间的性能，因此应该限制索引的大小和数量。
- 必要时不要添加索引。 确保它是必需的，并且它可提高查询的整体性能（测试和学习）。
- 一般而言，如果您知道查询不会返回超过10%的记录，索引将很有效。
- 仔细选择需要定义的索引。
- 请勿从现成表中删除本机索引。
示例
管理索引可能会变得非常复杂，因此了解它们的工作原理非常重要。 为了说明此复杂性，我们以一个基本示例为例，例如通过筛选名字和姓氏来搜索收件人。 操作步骤：
-
转到列出数据库中所有收件人的文件夹。 有关此内容的详细信息，请参阅管理用户档案。
-
右键单击 First name 字段。
-
选择 Filter on this field。
-
对 Last name 字段重复此操作。
屏幕顶部将添加两个相应的过滤器。
您现在可以根据各种筛选条件对 First name 和 Last name 字段执行搜索筛选。
现在，为了加快对这些过滤器的搜索，您可以添加索引。 但应该使用哪些索引？
下表显示了在哪些情况下根据第一列中显示的访问模式使用或不使用下述三个索引。
链接和基数 links-and-cardinality
链接 links
请注意大表上的“自身”完整性。 删除具有“自有”完整性的宽表的记录可以停止该实例。 表格被锁定，删除操作逐一进行。 因此，最好在有大卷的子表上使用“中性”完整性。
将链接声明为外部连接对性能不利。 零ID记录模拟外部连接功能。 如果链接使用autopk，则不必声明外部联接。
虽然可以在工作流中连接任何表，但Adobe建议直接在数据结构定义中定义资源之间的通用链接。
应根据表中的实际数据来定义链接。 错误定义可能会影响通过链接检索的数据，例如意外地重复记录。
使用与表名称一致的名称命名您的链接：链接名称应当有助于了解远程表是什么。
请勿将具有“id”的链接命名为后缀。 例如，将其命名为“transaction”，而不是“transactionId”。
默认情况下，Adobe Campaign将使用外部表的主键创建链接。 为清楚起见，最好在链接定义中明确定义连接。
将向链接中使用的属性添加索引。
此 “创建者”和“上次修改者”链接存在于许多表中。 如果业务未使用此信息，则可以使用链接上的属性noDbIndex禁用索引。
基数 cardinality
设计链接时，请确保在声明了1-1关系时目标记录是唯一的。 否则，当仅需要一条连接时，该连接可能会返回多条记录。 当“查询返回的行数多于预期值”时，这会在投放准备期间导致错误。 将链接名称设置为与目标架构相同的名称。
在(1)侧的架构中定义具有基数(1-N)的链接。 例如，应在事务模式中定义关系收件人(1) - (N)事务。
请注意，默认情况下，链接的反向基数为(N)。 可以通过向链接定义添加属性revCardinality='single'来定义链接(1-1)。
如果用户应该看不到反向链接，则可以使用链接定义revLink='NONE'隐藏该链接。 一个很好的用例是定义从收件人到完成的最后一个事务的链接，例如。 您只需要查看从收件人到最后交易的链接，不需要在交易表中显示反向链接。
执行外部联接(1-0…1)的链接应谨慎使用，因为它会影响系统性能。
数据保留 — 清理和清除 data-retention
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以外的数据仓库中。
- 生成聚合值，这些聚合值将占用较少的空间，同时足以满足您的营销实践需要。 例如，您不需要Adobe Campaign中的完整客户交易历史记录来跟踪上次购买。
您可以在架构中声明“deleteStatus”属性。 将记录标记为已删除，然后在清理任务中延迟删除会更有效。
性能 performance
为了确保随时获得更好的性能，请遵循以下最佳实践。
一般建议 general-recommendations
- 避免在查询中使用“CONTAINS”等操作。 如果您知道应该过滤哪些内容，并且希望对其进行过滤，请使用“EQUAL TO”或其他特定的过滤器运算符应用相同的条件。
- 在工作流中构建数据时，避免加入未编制索引的字段。
- 请尝试确保导入和导出等流程在工作时间之外执行。
- 确保所有日常活动都有一个时间表，并遵守时间表。
- 如果有一个或几个每日进程失败，并且如果必须在同一天运行它，请确保在启动手动进程时没有冲突进程在运行，因为这会影响系统性能。
- 确保在导入流程期间或执行任何手动流程时，不会运行任何每日营销活动。
- 使用一个或多个引用表，而不是在每行中复制字段。 使用键/值对时，最好选择数字键。
- 短字符串仍可接受。 如果引用表已在外部系统中，则重用它有助于将数据与Adobe Campaign集成。
一对多关系 one-to-many-relationships
- 数据设计会影响可用性和功能。 如果您设计的数据模型具有大量一对多关系，则会使用户更难以在应用程序中构建有意义的逻辑。 对于非技术性营销人员，可能很难正确构建和理解一对多过滤器逻辑。
- 将所有重要字段放在一个表中很好，因为这样用户更容易构建查询。 有时，如果可以避免联接，则跨表复制某些字段对性能也有好处。
- 某些内置功能无法引用一对多关系，例如优惠权重公式和投放。
大型表 large-tables
Adobe Campaign依赖于第三方数据库引擎。 根据提供商的不同，为较大的表优化性能可能需要特定的设计。
以下是使用大型表和复杂连接设计数据模型时应遵循的一些常见最佳实践。
- 使用其他自定义收件人表时，请确保您为每个投放映射创建了专用日志表。
- 减少列数，特别是通过标识未使用的列。
- 通过避免复杂连接（如多个条件和/或多个列上的连接）优化数据模型关系。
- 对于联接键，请始终使用数字数据，而不是字符串。
- 尽可能减少日志保留的深度。 如果需要更深入的历史记录，可以聚合计算和/或处理自定义日志表以存储更大的历史记录。
表的大小 size-of-tables
表大小是记录数和每条记录的列数的组合。 两者都会影响查询的性能。
- 小型 表类似于投放表。
- 中等大小 表与收件人表的大小相同。 每个客户都有一笔记录。
- large-size 表类似于Broad日志表。 每个客户都有许多记录。
例如，如果数据库包含1000万条收件人，则Broad日志表将包含约1亿到2亿条消息，而Delivery表将包含数千条记录。
在PostgreSQL上，行不应超过8 KB，以避免TOAST机制。 因此，应尽量减少列数和每行大小，以保持系统的最佳性能（内存和CPU）。
行数也会影响性能。 Adobe Campaign数据库的设计宗旨并非存储当前未用于定位或个性化目的的历史数据 — 这是一个操作数据库。
要防止出现与高行数相关的任何性能问题，请仅在数据库中保留必要的记录。 应将任何其他记录导出到第三方数据仓库，并从Adobe Campaign操作数据库中将其删除。
以下是有关表大小的几个最佳实践：
- 设计具有较少字段和更多数字数据的大型表。
- 请勿使用大数字类型的列（例如：Int64）存储布尔值等小数字。
- 从表定义中删除未使用的列。
- 请勿在Adobe Campaign数据库中保留历史数据或非活动数据（导出和清理）。
示例如下：
在此示例中：
- 事务 和 事务项 表很大：超过1000万。
- Product 和 Store 表更小：小于10,000。
- 产品标签和引用已放置在 Product 表中。
- 事务项 表仅具有指向 Product 表的链接，该表为数字形式。