数据模型最佳实践 data-model-best-practices
本文档概述了设计Adobe Campaign数据模型时的主要建议。
Adobe Campaign系统非常灵活，可以在初始实施之后扩展。 但是，尽管可能性是无限的，但做出明智决策并奠定坚实的基础来开始设计数据模型至关重要。
要更好地了解Campaign内置表以及它们之间的关系，请参阅此部分。
阅读此部分以开始使用Campaign架构。
在本页中了解如何配置扩展架构以扩展Adobe Campaign数据库的概念数据模型。
数据模型架构 data-model-architecture
Adobe Campaign是一款功能强大的跨渠道活动管理系统，可帮助您调整线上和线下策略以创建个性化的客户体验。
以客户为中心的做法 customer-centric-approach
虽然大多数电子邮件服务提供商都通过以列表为中心的方法与客户通信，但Adobe Campaign依靠关系数据库以更广泛地了解客户及其属性。
要访问每个表的说明，请转到 Admin > Configuration > Data schemas，从列表中选择资源，然后单击 Documentation 选项卡。
Adobe Campaign的数据 data-for-campaign
应将哪些数据发送到Adobe Campaign？ 确定营销活动所需的数据至关重要。
要决定是否需要在Adobe Campaign中使用某个属性，请问自己该属性是否属于以下类别之一：
- 用于 分段 的属性
- 用于 数据管理进程 的属性（例如，聚合计算）
- 用于 个性化 的属性
如果不属于上述任何一种，您很可能不会在Adobe Campaign中需要此属性。
数据类型选择 data-types
要确保良好的体系结构和系统性能，请遵循以下最佳实践在Adobe Campaign中设置数据。
- 在大表格中，可以插入字符串或数字字段，并添加指向引用表的链接（在使用值列表时）。
- expr 属性允许将架构属性定义为计算字段而不是表中的物理集值。 这样，用户就可以以不同的格式（例如年龄和出生日期）访问信息，而无需存储这两个值。 这是避免字段重复的好方法。 例如，收件人表使用域表达式，该表达式已存在于电子邮件字段中。
- 但是，当表达式计算复杂时，不建议使用 expr 属性，因为动态计算可能会影响查询的性能。
- XML 类型是避免创建过多字段的好方法。 但是，它也会占用磁盘空间，因为它使用数据库中的CLOB列。 它还可能导致复杂的SQL查询，并可能影响性能。
- 字符串 字段的长度应始终使用列定义。 默认情况下，Adobe Campaign中的最大长度为16K，但Adobe建议，如果您已经知道字段大小不会超过更短的长度，则请保持该字段的长度。
- 如果您确定源系统中的字段大小被高估而无法达到，则可以接受Adobe Campaign中的字段比源系统中的字段更短。 这可能意味着Adobe Campaign中的字符串长度更短，整数更小。
字段选择 choice-of-fields
如果某个字段具有定位或个性化目的，则需要将其存储在表中。 换言之，如果未使用字段发送个性化电子邮件或在查询中用作标准，则字段将不必要地占用磁盘空间。
键选择 choice-of-keys
除了大多数表中默认定义的 autouuid 和 autopk 之外，您还应考虑添加一些逻辑或业务密钥（帐号、客户端编号等）。 以后可用于导入/协调或数据包。 有关详细信息，请参阅标识符。
高效的密钥对于性能至关重要。 使用Snowflake，您可以将数字或基于字符串的数据类型作为表的键插入。
标识符 identifiers
Adobe Campaign资源具有三个标识符，可以添加额外的标识符。
下表描述了这些标识符及其用途。
- ID是Adobe Campaign表的物理主键。 对于内置表，它是一个通用唯一标识符(UUID)
- 此标识符必须是唯一的。
- UUID可以在架构定义中可见。
- 不应在工作流或包定义中将自动生成的标识符用作引用。
- 表中的ID是UUID，不应更改此类型。
- 此信息是表中记录的唯一标识符。 此值可手动更新，通常使用生成的名称。
- 当此标识符部署在Adobe Campaign的其他实例中时，会保留其值，并且它不应为空。
- 如果打算将对象从一个环境部署到另一个环境，请重命名Adobe Campaign生成的记录名称。
- 当对象具有命名空间属性（例如 架构）时，此公用命名空间将在创建的所有自定义对象中使用。 不应使用某些保留的命名空间： nms、xtk 等。 请注意，某些命名空间仅是内部命名空间。 了解详情。
- 当对象没有任何命名空间（例如 工作流 或 投放）时，此命名空间概念将被添加为内部名称对象的前缀： namespaceMyObjectName。
- 请勿使用空格“ ”、半列“：”或连字符“ — ”等特殊字符。 所有这些字符都将替换为下划线“_”（允许的字符）。 例如，“abc-def”和“abc：def”将存储为“abc_def”并相互覆盖。
- 标签是Adobe Campaign中对象或记录的业务标识符。
- 此对象允许使用空格和特殊字符。
- 它不能保证记录的唯一性。
- 建议确定对象标签的结构。
- 这是用于为Adobe Campaign用户标识记录或对象的最用户友好的解决方案。
在Enterprise (FFDA)部署的上下文中，Adobe Campaign主键是为所有内置表自动生成的UUID。 UUID也可用于自定义表。 了解详情
即使ID的数量是无限的，您也应该注意数据库的大小以确保最佳性能。 要防止出现任何问题，请确保调整实例清除设置。 有关更多信息，请参阅此小节。
自定义内部键 custom-internal-keys
在Adobe Campaign中创建的每个表都需要主键。
大多数组织正在从外部系统导入记录。 虽然收件人表的物理键是“id”属性，但也可以确定自定义键。
此自定义键是外部系统中馈送Adobe Campaign的实际记录主键。
创建自定义表时，您有两个选项：
- 自动生成的键(id)和内部键（自定义）的组合。 如果系统键是复合键或不是整数，则此选项很有趣。 使用Snowflake，整数或基于字符串的键将在大表中提供更高的性能，并可与其他表连接。
- 使用主键作为外部系统主键。 此解决方案通常是首选的，因为它简化了导入和导出数据的方法，在不同的系统之间使用了一致的密钥。 如果键名为“id”，并且应使用外部值填充（非自动生成），则应禁用 Autouuid。
- Autouuid不应用作工作流中的引用。
- autouuid 属性仅适用于Enterprise (FFDA)部署。
链接和基数 links-and-cardinality
链接 links
请注意大表上的“自身”完整性。 删除具有“自有”完整性的大表的记录可能会停止实例。 表格被锁定，删除操作逐一进行。 因此，最好在有大卷的子表上使用“中性”完整性。
将链接声明为外部连接对性能不利。 零ID记录模拟外部连接功能。 在Enterprise (FFDA)部署的上下文中，如果链接使用 autouuid，则不必声明外部联接。
虽然可以在工作流中连接任何表，但Adobe建议直接在数据结构定义中定义资源之间的通用链接。
应根据表中的实际数据来定义链接。 错误定义可能会影响通过链接检索的数据，例如意外地重复记录。
使用与表名称一致的名称命名您的链接：链接名称应当有助于了解远程表是什么。
请勿将具有“id”的链接命名为后缀。 例如，将其命名为“transaction”，而不是“transactionId”。
默认情况下，Adobe Campaign将使用外部表的主键创建链接。 为清楚起见，最好在链接定义中明确定义连接。
基数 cardinality
设计链接时，请确保在声明了1-1关系时目标记录是唯一的。 否则，当仅需要一条连接时，该连接可能会返回多条记录。 当“查询返回的行数多于预期值”时，这会在投放准备期间导致错误。 将链接名称设置为与目标架构相同的名称。
定义与(N)侧架构中基数(1-N)的链接。 例如，应在事务模式中定义关系收件人(1) - (N)事务。
请注意，默认情况下，链接的反向基数为(N)。 可以通过向链接定义添加属性revCardinality='single'来定义链接(1-1)。
如果用户应该看不到反向链接，则可以使用链接定义revLink='NONE'隐藏该链接。 一个很好的用例是定义从收件人到完成的最后一个事务的链接，例如。 您只需要查看从收件人到最后交易的链接，不需要在交易表中显示反向链接。
执行外部联接(1-0…1)的链接应谨慎使用，因为它会影响系统性能。
数据保留 data-retention
Adobe Campaign既不是Data Warehouse也不是报表工具。 因此，要确保Adobe Campaign解决方案具有良好的性能，应控制数据库增长。 要实现这一点，遵循以下一些最佳实践可能会有所帮助。
关于保留时间，Campaign 中的内置日志表具有预设的保留期，通常将其数据存储限制为 6 个月或更短时间。
以下是内置表的默认保留时间值。请注意，保留时间配置由 Adobe 技术管理员在实施期间设置，每项实施的值可能因客户要求而异。
- 整合跟踪：1 年
- 投放日志：6 个月
- 跟踪日志：1 年
- 已删除的投放：1 周
- 被拒绝的导入内容：6 个月
- 访客用户档案：1 个月
- 优惠建议：1 年
- 事件：1 个月
- 事件处理统计信息：1 年
- 存档事件：1 年
- 已忽略的渠道事件：1 个月
有几个解决方案可以最大程度地减少Adobe Campaign中的记录需求：
- 将数据导出到Adobe Campaign以外的数据仓库中。
- 生成聚合值，这些聚合值将占用较少的空间，同时足以满足您的营销实践需要。 例如，您不需要Adobe Campaign中的完整客户交易历史记录来跟踪上次购买。
您可以在架构中声明“deleteStatus”属性。 将记录标记为已删除，然后在清理任务中延迟删除会更有效。
作为托管Cloud Service用户，请联系Adobe顾问或技术管理员，以详细了解保留，或者您是否需要为自定义表设置保留。
性能 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表将包含数千条记录。
行数也会影响性能。 Adobe Campaign数据库的设计宗旨并非存储当前未用于定位或个性化目的的历史数据 — 这是一个操作数据库。
要防止出现与高行数相关的任何性能问题，请仅在数据库中保留必要的记录。 应将任何其他记录导出到第三方数据仓库，并从Adobe Campaign操作数据库中将其删除。
以下是有关表大小的几个最佳实践：
- 设计具有较少字段和更多数字数据的大型表。
- 请勿使用大数字类型的列来存储小数字，如布尔值。
- 从表定义中删除未使用的列。
- 请勿在Adobe Campaign数据库中保留历史数据或非活动数据（导出和清理）。