資料模型最佳實務

本文檔概述了設計Adobe Campaign資料模型時的主要建議。

要更好地瞭解活動內置表及其交互作用，請參閱 此部分 的子菜單。

讀出 本文檔 以開始使用市場活動架構。 瞭解如何配置擴展架構以擴展Adobe Campaign資料庫的概念資料模型 此文檔。

概覽

Adobe Campaign系統極其靈活，可以擴展到最初的實施之外。 但是，儘管可能性是無限的，但做出明智決策並建立堅實的基礎是開始設計您的資料模型的關鍵。

本文檔提供了常見使用案例和最佳做法，以瞭解如何正確設計您的Adobe Campaign工具。

資料模型體系結構

Adobe Campaign是一個功能強大的跨渠道市場活動管理系統，可幫助您調整線上和離線策略以創造個性化的客戶體驗。

以客戶為中心的方法

雖然大多數電子郵件服務提供商都在通過以清單為中心的方式與客戶進行溝通，但Adobe Campaign卻依賴關係資料庫來利用客戶及其屬性的更廣泛視圖。

以客戶為中心的方法如下圖所示。 的 收件人 灰色表表示正圍繞其構建一切的主要客戶表：

要訪問每個表的說明，請轉到 Admin > Configuration > Data schemas，從清單中選擇資源，然後按一下 Documentation 頁籤。

Adobe Campaign預設資料模型在 此文檔。

注意

Adobe Campaign Classic允許構建自定義客戶表。 但是，在大多數情況下，建議利用標準 收件人表 已預先構建了其他表和功能。

Adobe Campaign資料

哪些資料應該發送到Adobe Campaign? 確定您的營銷活動所需的資料至關重要。

注意

Adobe Campaign既不是資料倉庫，也不是報告工具。 因此，不要嘗試將所有可能的客戶及其關聯資訊導入Adobe Campaign，或導入僅用於生成報告的資料。

要決定在Adobe Campaign是否需要某個屬性，請問問自己是否屬於以下類別：

  • 用於 分割
  • 用於 資料管理流程 （例如，聚合計算）
  • 用於 個性化

如果不是陷入其中，你很可能不需要這個屬性在Adobe Campaign。

資料類型選擇

為確保系統的良好體系結構和效能，請遵循以下最佳實踐在Adobe Campaign設定資料。

  • 大表應大多包含數字欄位，並包含指向引用表的連結（使用值清單時）。
  • 的 EXPR 屬性允許將模式屬性定義為計算欄位，而不是表中的物理集值。 這可以使用不同格式（例如年齡和出生日期）訪問資訊，而無需儲存這兩個值。 這是避免重複欄位的好方法。 例如，「收件人」表使用域的表達式，該表達式已存在於電子郵件欄位中。
  • 但是，當表達式計算複雜時，建議不要使用 EXPR 屬性作為即時計算可能會影響查詢的效能。
  • 的 XML 類型是避免建立過多欄位的好方法。 但是，它也佔用了磁碟空間，因為它使用資料庫中的CLOB列。 它還可能導致複雜的SQL查詢，並可能影響效能。
  • 長度 字串 欄位應始終與列一起定義。 預設情況下，Adobe Campaign的最大長度為255，但Adobe建議，如果您已經知道該大小不會超過較短的長度，則保持該欄位的較短。
  • 如果您確定源系統中的欄位被高估而無法達到，則可以接受在Adobe Campaign使用的欄位比源系統中的欄位短。 這可能意味著Adobe Campaign的字串較短或整數較小。

欄位選擇

如果欄位具有目標或個性化目的，則需要將其儲存在表中。 換句話說，如果某個欄位未用於發送個性化電子郵件或用作查詢中的標準，則會佔用磁碟空間，而它無用。

對於混合型和內部部署型實例，FDA（聯合資料存取，一種允許訪問外部資料的可選功能）涵蓋了在活動過程中「即時」添加欄位的需要。 如果你有食品藥品管理局，你就不需要進口任何東西。 有關此的詳細資訊，請參閱 關於聯合資料存取。

鍵的選擇

除 奧托普 在大多數表中預設定義，您應考慮添加一些邏輯或業務密鑰（帳號、客戶機號等）。 以後可將其用於導入/協調或資料包。 有關此的詳細資訊，請參閱 標識符。

高效的密鑰對效能至關重要。 數值資料類型應始終作為表的鍵。

對於SQLServer資料庫，如果需要效能，可以考慮使用「聚簇索引」。 由於Adobe不處理此問題，因此需要在SQL中建立它。

專用表空間

方案中的表空間屬性允許您為表指定專用表空間。

安裝嚮導允許您按類型（資料、臨時和索引）儲存對象。

專用表空間更適合分區、安全規則，並允許流暢、靈活的管理、更好的優化和效能。

標識符

Adobe Campaign資源有三個標識符，並且可以添加一個附加標識符。

下表介紹了這些標識符及其用途。

標識符 說明 最佳實務
ID
  • ID是Adobe Campaign表的物理主鍵。 對於現成表，它是從序列中生成的32位數
  • 此標識符通常對特定的Adobe Campaign實例唯一。
  • 在架構定義中可以看到自動生成的ID。 搜索 autopk="true" 屬性。
  • 自動生成的標識符不應用作工作流或包定義中的引用。
  • 不應假設id將始終為遞增數。
  • 現成表中的ID是32位數，不應更改此類型。 此編號取自同名節中所涵蓋的「序列」。
名稱（或內部名稱）
  • 此資訊是表中記錄的唯一標識符。 此值可以手動更新，通常使用生成的名稱。
  • 此標識符在部署到Adobe Campaign的其他實例時保留其值，不應為空。
  • 如果對象要從環境部署到另一個環境，請更名Adobe Campaign生成的記錄名稱。
  • 當對象具有命名空間屬性(架構 例如)，此公共命名空間將用於所有建立的自定義對象。 不應使用某些保留的命名空間： nms。 xtk。 n。 無。 crm。 xxl。
  • 當對象沒有任何命名空間(工作流 或 交貨 例如)，此命名空間概念將作為內部名稱對象的前置詞添加： 命名空間MyObjectName。
  • 請勿使用特殊字元，如空格「」、半列「：」或連字元「 — 」。 所有這些字元都將替換為下划線「_」（允許的字元）。 例如，「abc-def」和「abc:def」將儲存為「abc_def」，並互相覆蓋。
標籤
  • 標籤是Adobe Campaign中對象或記錄的業務標識符。
  • 此對象允許空格和特殊字元。
  • 它不能保證記錄的唯一性。
  • 建議確定對象標籤的結構。
  • 這是標識Adobe Campaign用戶的記錄或對象的最方便用戶的解決方案。

自定義內部鍵

在Adobe Campaign建立的每個表都需要主鍵。

大多陣列織正在從外部系統導入記錄。 雖然Recipient表的物理鍵是"id"屬性，但可以另外確定自定義鍵。

此自定義鍵是外部系統饋送Adobe Campaign的實際記錄主鍵。

當現成表同時具有自動密鑰和內部密鑰時，內部密鑰將被設定為物理資料庫表中的唯一索引。

建立自定義表時，有兩個選項：

  • 自動生成的密鑰(id)和內部密鑰（自定義）的組合。 如果系統鍵是複合鍵或不是整數，則此選項很有意義。 整數在大表中提供更高的效能，並與其他表聯接。
  • 使用主鍵作為外部系統主鍵。 此解決方案通常是首選的，因為它簡化了資料導入和導出的方法，並且在不同的系統之間具有一致的密鑰。 如果鍵名為「id」，並預期用外部值填充（不是自動生成），則應禁用Autopk。
重要

在工作流中，不應將自動編輯用作引用。

序列

Adobe Campaign主鍵是所有出廠設定表的自動生成的ID，對於自定義表可以是相同的。 如需詳細資訊，請參閱本節。

此值取自稱為 序列，是用於生成編號規則的資料庫對象。

序列有兩種類型：

  • 共用:多個表會從同一序列中選擇其id。 這意味著，如果一個表使用ID「X」，則共用同一序列的其他表將沒有具有該ID「X」的記錄。 XtkNewId 是在Adobe Campaign可用的預設共用序列。
  • 專用:只有一個表從序列中挑選其id。 序列名通常包含表名。
重要

序列是一個32位的整數值，其可用值的最大數量有限：21.4億。 在達到最大值後，序列將返回0以回收ID。

如果舊資料未清除，則結果將是唯一密鑰違規，這將成為平台運行狀況和使用情況的阻止程式。 Adobe Campaign將無法發送通信（當它影響到交付日誌表時），效能將受到很大影響。

因此，如果客戶每年發送60億封電子郵件，其日誌的保留期為180天，則4個月內就會用完ID。 要防止出現此類問題，請確保根據卷設定清除設定。 如需詳細資訊，請參閱本節。

當在Adobe Campaign建立具有主鍵autoPK的自定義表時，應將自定義專用序列系統地與該表關聯。

預設情況下，自定義序列的值範圍為+1,000到+2.1BB。 從技術上講，通過啟用負ID，可以獲得4BB的全範圍。 應謹慎使用，從負數到正數時，將丟失一個id:記錄0通常被Adobe Campaign在生成的SQL查詢中忽略。

要瞭解更多關於序列耗盡的資訊，請觀察 這個視頻。

索引

索引對效能至關重要。 在架構中聲明密鑰時，Adobe將自動在密鑰的欄位上建立索引。 您還可以為不使用鍵的查詢聲明更多索引。

Adobe建議定義附加索引，因為它可能會提高效能。

但是，請記住以下幾點：

  • 索引用法已綁定到您的訪問模式。 優化索引通常是資料庫設計中的關鍵部分，必須由專家來處理。 添加索引通常是附加到資料庫維護的迭代工作流。 它會隨著時間的推移逐步地完成，以解決發生時的效能問題。
  • 索引增加了表的總大小（以儲存索引本身）。
  • 在列上添加索引可以提高資料讀訪問(SELECT)的效能，但會降低資料寫訪問(UPDATE)的效能。
  • 由於這會影響插入資料時的效能，因此索引應限制在大小和數量上。
  • 不必添加索引。 確保需要它，並提高查詢的整體效能(test和學習)。
  • 一般來說，如果您知道您的查詢不會帶回超過10%的記錄，則索引是有效的。
  • 仔細選擇需要定義的索引。
  • 不要從現成表中刪除本機索引。

範例

管理索引可能會變得非常複雜，因此瞭解索引如何工作非常重要。 為了說明這種複雜性，讓我們舉一個基本的示例，例如，通過對名字和姓氏進行篩選來搜索收件人。 操作步驟：

  1. 轉到列出資料庫中所有收件人的資料夾。 有關此的詳細資訊，請參閱 管理配置檔案。

  2. 按一下右鍵 First name 的子菜單。

  3. 選取 Filter on this field。

  4. 對 Last name 的子菜單。

兩個對應的濾鏡被添加到螢幕頂部。

現在，您可以對 First name 和 Last name 欄位。

現在，要加快對這些篩選器的搜索，可以添加索引。 但應使用哪些索引？

注意

此示例適用於使用PostgreSQL資料庫的托管客戶。

下表顯示了在哪些情況下，根據第一列中顯示的訪問模式使用或不使用下面描述的三個索引。

搜索條件 索引1（名+姓） 索引2（僅名） 索引3（僅姓氏） 注釋
名字等於強尼。 已用 已用 未使用 由於名字在索引1上處於第一位置，因此仍將使用它：不需要在姓氏上添加條件。
名字等於"Johnny"，姓氏等於"Smith" 已用 未使用 未使用 由於在同一查詢中搜索兩個屬性，因此將只使用合併兩個屬性的索引。
姓氏等於"史密斯" 未使用 未使用 已用 索引中屬性的順序被考慮在內。 如果與此順序不匹配，則可能不使用索引。
名字以"Joh"開頭 已用 已用 未使用 「左搜索」將啟用索引。
名字以"ny"結尾 未使用 未使用 未使用 「正確搜索」將禁用索引，並將執行完全掃描。 某些特定索引類型可以處理此使用情形，但預設情況下在Adobe Campaign不可用。
名字包含"John" 未使用 未使用 未使用 這是「left」和「right」搜索的組合。 由於後者，它將禁用索引，並執行完全掃描。
名字等於"john" 未使用 未使用 未使用 索引區分大小寫。 要使其不區分大小寫，應建立包含SQL函式(如「upper(firstname)」)的特定索引。 您應該對其他資料轉換(如「unaccent(firstname)」)執行同樣的操作。

謹防大桌上的「自己」誠信。 刪除具有「自有」完整性的寬表的記錄可以停止實例。 表被鎖定，刪除操作逐個進行。 所以最好在大容量的子表上使用"中性"完整性。

將連結聲明為外部連接對效能不利。 零ID記錄模擬外部連接功能。 如果連結使用autopk ，則無需聲明外部連接。

雖然可以將任何表加入工作流中，但Adobe建議直接在資料結構定義中定義資源之間的公用連結。

連結應與表中的實際資料對齊定義。 錯誤的定義可能影響通過連結檢索到的資料，例如意外地複製記錄。

使用表名稱一致命名連結：連結名稱應有助於瞭解遠程表是什麼。

不要將「id」作為尾碼的連結命名。 例如，將其命名為「transaction」，而不是「transactionId」。

預設情況下，Adobe Campaign將使用外部表的主鍵建立連結。 為了更清晰，最好在連結定義中顯式定義連接。

索引將添加到連結中使用的屬性。

建立者連結和上次修改者連結在許多表中都存在。 如果業務未使用此資訊，則可以通過在連結上使用屬性noDbIndex來禁用索引。

基數

設計連結時，確保在聲明1-1關係時目標籤錄是唯一的。 否則，當僅需要一條記錄時，連接可能會返回多個記錄。 當「查詢返回的行數超出預期」時，這會在準備交貨期間導致錯誤。 將連結名稱設定為與目標架構相同的名稱。

在(1)側的架構中定義帶基數(1-N)的連結。 例如，應在事務架構中定義關係收件人(1)-(N)事務。

請注意，連結的反向基數預設為(N)。 通過將屬性revCardinality='singe'添加到連結定義中，可以定義連結(1-1)。

如果用戶不能看到反向連結，則可以使用連結定義revLink='隱藏它​無「 」。 這方面的一個很好的使用案例是，例如，定義從收件人到完成的最後一個事務的連結。 您只需查看從收件人到最後一個事務處理的連結，並且不需要從事務處理表中看到任何反向連結。

執行外部連接(1-0…1)的連結應謹慎使用，因為它將影響系統效能。

資料保留 — 清理和清除

Adobe Campaign既不是資料倉庫，也不是報告工具。 因此，為確保Adobe Campaign解決方案的良好效能，資料庫增長應保持在控制之下。 為了實現這一目標，遵循以下一些最佳做法可能會有所幫助。

預設情況下，Adobe Campaign交付和跟蹤日誌的保留期為180天。 運行清除進程以刪除早於該進程的所有日誌。

  • 如果希望將日誌保留更長時間，則應根據資料庫大小和發送的消息量仔細作出此決定。 作為提醒，Adobe Campaign序列是32位整數。
  • 建議在這些表中一次不要有超過10億條記錄（21.4億個ID中的50%），以限制使用所有可用ID的風險。 這要求某些客戶將保留期限降低到180天以下。

瞭解有關中資料保留的詳細資訊 市場活動隱私和安全准則。

瞭解有關市場活動資料庫清理工作流的詳細資訊 此部分。

重要

自定義表不會使用標準清除過程清除。 雖然在第一天可能不需要這樣做，但不要忘記為自定義表構建清除流程，因為這可能會導致效能挑戰。

有幾種解決方案可最大限度地減少對Adobe Campaign記錄的需求：

  • 在Adobe Campaign以外的資料倉庫中導出資料。
  • 生成集合值，以減少空間，同時滿足您的營銷慣例。 例如，您不需要Adobe Campaign的完整客戶交易記錄記錄來跟蹤上次採購。

可以在架構中聲明「deleteStatus」屬性。 將記錄標籤為已刪除，然後延遲清除任務中的刪除，這樣更有效。

效能

為確保在任何時間都能獲得更好的效能，請遵循以下最佳做法。

一般性建議

  • 避免在查詢中使用「CONTAINS」等操作。 如果知道預期的內容並希望過濾，請將相同條件與「EQUAL TO」或其他特定篩選器運算子一起應用。
  • 在工作流中生成資料時，避免與非索引欄位連接。
  • 請確保在工作時間之外執行導入和導出等過程。
  • 確保有所有日常活動的時間表，並遵守時間表。
  • 如果日進程中的一個或幾個失敗，並且必須在當天運行，請確保在手動進程啟動時沒有運行衝突的進程，因為這可能會影響系統效能。
  • 確保在導入流程期間或執行任何手動流程期間未運行任何每日市場活動。
  • 使用一個或多個引用表，而不是在每行中複製欄位。 使用鍵/值對時，最好選擇數字鍵。
  • 短字串仍然可接受。 如果引用表已在外部系統中就位，則重新使用它將有助於與Adobe Campaign的資料整合。

一對多關係

  • 資料設計影響可用性和功能性。 如果您設計的資料模型具有許多一對多關係，則用戶在應用程式中構造有意義的邏輯會更加困難。 一對多過濾邏輯對於非技術營銷人員來說很難正確構造和理解。
  • 將所有基本欄位放在一個表中是件好事，因為它使用戶更容易生成查詢。 有時，如果可以避免聯接，則在表間複製某些欄位也對效能有利。
  • 某些內置功能將不能引用一對多關係，例如「提供加權公式」和「交付」。

大表

Adobe Campaign依靠第三方資料庫引擎。 根據提供程式的不同，為較大的表優化效能可能需要特定的設計。

以下是使用大型表和複雜連接設計資料模型時應遵循的一些常見最佳做法。

  • 使用其他自定義收件人表時，請確保每個傳遞映射都有專用的日誌表。
  • 減少列數，特別是通過標識未使用的列數。
  • 通過避免複雜的連接（例如在若干條件和/或幾列上的連接）來優化資料模型關係。
  • 對於聯接鍵，請始終使用數字資料而不是字串。
  • 盡可能減少日誌保留深度。 如果需要更深的歷史記錄，可以聚合計算和/或處理自定義日誌表以儲存更大的歷史記錄。

表的大小

表大小是記錄數和每個記錄列數的組合。 這兩種方法都會影響查詢的效能。

  • A 小尺寸 表與「傳遞」表類似。
  • A 中等大小 表與收件人表的大小相同。 每個客戶有一條記錄。
  • A 大尺寸 表與Broad日誌表類似。 每個客戶都有許多記錄。
    例如，如果資料庫包含1000萬收件人，則Broad日誌表包含大約1億到2億條消息，而Delivery表包含幾千條記錄。

在PostgreSQL上，行不應超過8KB以避免 吐司 機制。 因此，請盡量減少列數和每行的大小，以保留系統（記憶體和CPU）的最佳效能。

行數也會影響效能。 Adobe Campaign資料庫不用於儲存未用於目標或個性化目的的歷史資料 — 這是一個操作資料庫。

要防止與行數過多相關的任何效能問題，請僅在資料庫中保留必要的記錄。 任何其他記錄應導出到第三方資料倉庫，並從Adobe Campaign業務資料庫中刪除。

以下是關於表大小的一些最佳做法：

  • 設計欄位較少、數字資料較多的大型表。
  • 不要使用大數量的列類型(例如：Int64)，用於儲存小數字（如布爾值）。
  • 從表定義中刪除未使用的列。
  • 不要將歷史資料或非活動資料保留在Adobe Campaign資料庫中（導出和清除）。

下面是一個示例：

在此示例中：

  • 的 交易記錄 和 事務處理物料 表很大：超過一千萬。
  • 的 產品 和 儲存 表較小：不到一萬。
  • 產品標籤和引用已放置在 產品 的子菜單。
  • 的 事務處理物料 表僅具有指向 產品 表，這是數字。

本頁內容