資料模型最佳實務

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

如需深入了解Campaign內建表格及其互動，請參閱此區段區段。

請閱讀本檔案，以開始使用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是否需要某個屬性，請問自己是否屬於以下類別之一：

  • 用於​segmentation​的屬性
  • 用於​資料管理進程​的屬性（例如聚合計算）
  • 用於​個人化​的屬性

若未落入其中任何一個，您很可能在Adobe Campaign中不需要此屬性。

資料類型選擇

若要確保系統的良好架構和效能，請遵循下列最佳實務，在Adobe Campaign中設定資料。

  • 大型表格大多應具有數值欄位，並包含參考表格的連結（使用值清單時）。
  • expr​屬性允許將架構屬性定義為計算欄位，而非表中的物理集值。 這可以讓您以不同格式（例如年齡和出生日期）存取資訊，而不需要儲存這兩個值。 這是避免重複欄位的好方法。 例如，「收件者」表格會使用網域的運算式，而此運算式已出現在電子郵件欄位中。
  • 但是，當運算式計算複雜時，不建議使用​expr​屬性作為即時計算，可能會影響查詢的效能。
  • XML​類型是避免建立過多欄位的好方法。 但它也佔用了磁碟空間，因為它使用資料庫中的CLOB列。 它還可能導致複雜的SQL查詢，並可能影響效能。
  • string​欄位的長度應一律以欄定義。 依預設，Adobe Campaign中的最大長度為255，但如果您已知道大小不會超過較短的長度，則Adobe建議將欄位保持在較短的長度。
  • 如果您確定源系統中的欄位被高估且無法達到，則可以接受在Adobe Campaign中的欄位比在源系統中的欄位短。 這可能表示Adobe Campaign中字串較短或整數較小。

欄位選擇

如果欄位具有定位或個人化目的，則必須將其儲存在表格中。 換句話說，如果欄位未用來傳送個人化電子郵件，或用作查詢中的標準，則會佔用磁碟空間，但是沒用。

針對混合式和內部部署例項，FDA（同盟資料存取，此選用功能可存取外部資料）涵蓋在行銷活動程式期間需要新增「即時」欄位。 如果您有FDA，則不需要匯入所有項目。 有關詳細資訊，請參閱關於同盟資料存取。

鍵的選擇

除了大多數表中預設定義的​autopk​之外，您還應考慮添加一些邏輯或業務密鑰（帳號、客戶端編號等）。 它稍後可用於匯入/調解或資料包。 有關詳細資訊，請參閱標識符。

高效的密鑰對效能至關重要。 數值資料類型應一律作為表格的索引鍵。

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

專用表空間

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

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

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

識別碼

Adobe Campaign資源有三個識別碼，且可以新增其他識別碼。

下表說明這些識別碼及其用途。

識別碼 說明 最佳實務
Id
  • id是Adobe Campaign表的物理主鍵。 對於現成的表，它是從序列中生成的32位數字
  • 此識別碼通常對特定Adobe Campaign例項不重複。
  • 自動產生的ID可顯示在架構定義中。 搜尋​autopk="true"​屬性。
  • 自動產生的識別碼不應作為工作流程或套件定義中的參考。
  • 不應假設ID一律會是遞增的數字。
  • 現成可用表格中的id是32位元數字，此類型不應變更。 此數字取自於區段中以相同名稱涵蓋的「序列」。
名稱（或內部名稱）
  • 此資訊是表中記錄的唯一標識符。 此值可手動更新，通常具有產生的名稱。
  • 此識別碼會在部署至不同的Adobe Campaign例項時保留其值，且不應為空。
  • 如果要將物件從環境部署至另一個環境，請重新命名Adobe Campaign產生的記錄名稱。
  • 當對象具有命名空間屬性（例如​schema）時，此通用命名空間將用於所有建立的自定義對象。 不應使用某些保留的命名空間：nms, xtk, nl, ncl, crm, xxl。
  • 當物件沒有任何命名空間時（例如​workflow​或​delivery），此命名空間概念將新增為內部名稱物件的前置詞：namespaceMyObjectName。
  • 請勿使用特殊字元，例如空格" "、半欄":"或連字型大小"-"。 所有這些字元都將替換為底線「_」（允許的字元）。 例如，「abc-def」和「abc:def」會儲存為「abc_def」並互相覆寫。
標籤
  • 標籤是Adobe Campaign中物件或記錄的業務識別碼。
  • 此對象允許空格和特殊字元。
  • 它不能保證記錄的獨特性。
  • 建議您判斷物件標籤的結構。
  • 這是最方便使用者為Adobe Campaign使用者識別記錄或物件的解決方案。

自訂內部索引鍵

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

大多陣列織都從外部系統導入記錄。 雖然Recipient表的物理密鑰是「id」屬性，但您還可以確定自定義密鑰。

此自訂金鑰是外部系統饋送Adobe Campaign的實際記錄主金鑰。

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

建立自訂表格時，有兩個選項：

  • 自動產生的金鑰(id)和內部金鑰（自訂）的組合。 如果您的系統密鑰是複合密鑰或不是整數，則此選項很有趣。 整數在大表中提供更高的效能，並與其他表連接。
  • 使用主鍵作為外部系統主鍵。 此解決方案通常較為理想，因為它簡化了資料匯入和匯出的方法，且在不同系統之間具有一致的鍵值。 如果索引鍵名為「id」，且預期會填入外部值（非自動產生），則應停用Autopk。
重要

作者不應作為工作流程中的參考。

序列

Adobe Campaign主索引鍵是所有現成可用表格的自動產生id，而自訂表格則可能相同。 如需詳細資訊，請參閱本節。

此值取自於​sequence，該序列是用於生成編號序列的資料庫對象。

序列有兩種類型：

  • 共用:多個表格會從相同序列中挑選其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:Adobe Campaign通常會在產生的SQL查詢中忽略記錄0。

相關主題：

  • 有關​序列自動生成​功能的詳細資訊，請參閱本文檔。
  • 如需序列耗盡的詳細資訊，請觀看此影片。

索引

索引對效能至關重要。 當您在架構中宣告索引鍵時，Adobe會自動在索引鍵的欄位上建立索引。 您也可以為未使用索引鍵的查詢聲明更多索引。

Adobe建議定義其他索引，因為這可能改善效能。

不過，請記住下列事項：

  • 索引使用情況已綁定到您的訪問模式。 最佳化索引往往是資料庫設計中的一個關鍵部分，必須由專家處理。 添加索引通常是附加到資料庫維護的迭代工作流。 會隨著時間逐步完成，以解決發生時的效能問題。
  • 索引會增加總表大小（以儲存索引本身）。
  • 在列上添加索引可以提高資料讀取訪問(SELECT)的效能，但可以降低資料寫入訪問(UPDATE)的效能。
  • 由於這會影響資料插入期間的效能，因此索引的大小和數量應受到限制。
  • 不需要時不添加索引。 請確定此為必要項目，並提高查詢的整體效能（測試和學習）。
  • 一般而言，如果您知道您的查詢不會傳回超過10%的記錄，則索引是有效的。
  • 請謹慎選取需要定義的索引。
  • 請勿從現成可用的表中刪除本機索引。

範例

管理索引可能會變得非常複雜，因此了解索引的運作方式非常重要。 為了說明此複雜性，我們以一個基本範例來說明，例如透過篩選名字和姓氏來搜尋收件者。 操作步驟：

  1. 移至列出資料庫中所有收件者的資料夾。 如需詳細資訊，請參閱管理設定檔。

  2. 按一下右鍵​First name​欄位。

  3. 選取 Filter on this field。

  4. 對​Last name​欄位重複此操作。

兩個對應的篩選器會新增至畫面頂端。

您現在可以根據各種篩選條件，對​First name​和​Last name​欄位執行搜尋篩選。

現在，若要加快對這些篩選器的搜尋，您可以新增索引。 但應該使用哪些索引？

注意

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

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

搜尋條件 索引1（名字+姓氏） 索引2（僅名字） 索引3（僅姓氏） 註解
名字等於「強尼」 已使用 已使用 未使用 由於名字在索引1上的第一個位置，因此仍將使用它：無需在姓氏上新增條件。
名字等於「Johnny」，姓氏等於「Smith」 已使用 未使用 未使用 由於同一查詢中同時搜索了兩個屬性，因此將只使用結合這兩個屬性的索引。
姓氏等於「Smith」 未使用 未使用 已使用 索引中的屬性順序被考慮在內。 如果不符合此順序，則可能不使用索引。
名字以"Joh"開頭 已使用 已使用 未使用 「左搜索」將啟用索引。
名字的結尾是「nny」 未使用 未使用 未使用 「正確搜索」將禁用索引，並執行完整掃描。 某些特定索引類型可處理此使用案例，但預設無法在Adobe Campaign中使用。
名字包含「John」 未使用 未使用 未使用 這是「左」和「右」搜尋的組合。 因為後者，它將禁用索引，並執行完整掃描。
名字等於「john」 未使用 未使用 未使用 索引區分大小寫。 要使其不區分大小寫，應建立包含SQL函式(如"upper(firstname)")的特定索引。 您應該對其他資料轉換(例如「unaccent(firstname)」)執行相同操作。

請注意大表上的「自己」完整性。 刪除具有「自有」完整性的寬表的記錄可以停止實例。 表已鎖定，且逐個刪除。 因此，最好對具有大容量的子表使用「中性」完整性。

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

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

連結的定義應與表格中的實際資料一致。 錯誤的定義可能會影響透過連結擷取的資料，例如意外重複記錄。

以表格名稱一致地為連結命名：連結名稱應有助於了解遠距表格的內容。

請勿將連結命名為尾碼為「id」。 例如，將其命名為「transaction」，而非「transactionId」。

依預設，Adobe Campaign會使用外部表格的主要索引鍵建立連結。 為了更清楚明瞭，最好在連結定義中明確定義連結。

索引將新增至連結中使用的屬性。

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

基數

當您設計連結時，請確定在宣告1-1關係時目標籤錄是唯一的。 否則，當只需要一條記錄時，連接可能會返回多條記錄。 這會在傳送準備期間發生錯誤，當「查詢傳回的列數超過預期」時。 將連結名稱設定為與目標架構相同的名稱。

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

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

如果用戶不能看到反向連結，則可以使用連結定義revLink='NONE'來隱藏它。 例如，一個很好的使用案例是定義從收件者到最後完成交易的連結。 您只需查看從收件者到最後一個交易的連結，並且無需從交易表中看到任何反向連結。

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

資料保留 — 清除和清除

Adobe Campaign既非資料倉庫，也非報表工具。 因此，為確保Adobe Campaign解決方案的良好效能，應控制資料庫的增長。 為達成此目標，遵循下列一些最佳實務可能有所幫助。

依預設，Adobe Campaign傳送和追蹤記錄的保留期間為180天。 清除程式會執行以移除任何早於該程式的記錄。

  • 如果您想要讓記錄保留更長時間，應根據資料庫大小和傳送的訊息數量，謹慎做出此決定。 提醒您，Adobe Campaign序列是32位元整數。
  • 建議不要在這些表中一次擁有超過10億條記錄（21.4億個可用ID中的50%），以限制使用所有可用ID的風險。 部分客戶需要將保留期限降至180天以下。

在Campaign隱私權與安全性准則中深入了解資料保留。

在本小節🔗中深入了解Campaign資料庫清理工作流程。

重要

自訂表格不會透過標準清除程式清除。 雖然在第一天可能不需要這項操作，但別忘了為自訂表格建立清除程式，因為這可能會導致效能挑戰。

有幾種解決方案可將Adobe Campaign中記錄的需求降至最低：

  • 匯出Adobe Campaign以外資料倉庫中的資料。
  • 產生匯總值，以減少空間，同時滿足您的行銷實務需求。 例如，您不需要Adobe Campaign中的完整客戶交易記錄，即可追蹤上次購買。

您可以在架構中宣告「deleteStatus」屬性。 將記錄標示為已刪除，然後延遲清除任務中的刪除會更有效。

效能

為了隨時確保效能更佳，請遵循下列最佳實務。

一般性建議

  • 避免在查詢中使用「CONTAINS」等操作。 如果您知道需要什麼並且想要篩選，請使用「等於」或其他特定篩選運算子套用相同條件。
  • 在工作流程中建立資料時，請避免加入非索引欄位。
  • 請嘗試確保在工作時間完成匯入和匯出等程式。
  • 請確定所有每日活動都有排程並遵守排程。
  • 如果日常進程中的一個或幾個失敗，並且如果強制在同一天運行該進程，請確保在啟動手動進程時沒有運行衝突進程，因為這可能影響系統效能。
  • 請確定在匯入程式期間或執行任何手動程式期間，沒有執行任何每日促銷活動。
  • 使用一個或多個引用表，而不是在每行中重複一個欄位。 使用索引鍵/值組時，最好選擇數值索引鍵。
  • 短字串仍可接受。 如果外部系統中已有參考表格，則重複使用這些表格將有助於與Adobe Campaign的資料整合。

一對多關係

  • 資料設計會影響可用性和功能。 如果您設計的資料模型具有許多一對多關係，則會讓使用者更難在應用程式中建構有意義的邏輯。 非技術行銷人員可能難以正確建構及了解一對多篩選邏輯。
  • 將所有必要欄位放在一個表格中是件好事，因為這可讓使用者更輕鬆地建立查詢。 有時，如果可以避免加入，則跨表複製某些欄位對效能也有好處。
  • 某些內建功能將無法參考一對多關係，例如選件加權公式和傳送。

大表

Adobe Campaign仰賴協力廠商資料庫引擎。 根據提供程式，為較大表優化效能可能需要特定設計。

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

  • 使用其他自訂收件者表格時，請務必為每個傳送對應提供專用的記錄表。
  • 減少欄數，尤其是識別未使用的欄數。
  • 通過避免複雜的聯接（例如在多個條件和/或多個列上的聯接）來優化資料模型關係。
  • 對於聯接鍵，請始終使用數字資料，而不是字元字串。
  • 盡量減少記錄保留的深度。 如果您需要更深入的歷史記錄，則可以匯總計算和/或處理自定義日誌表以儲存較大的歷史記錄。

表大小

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

  • 小型​表與「傳送」表類似。
  • 中等大小​表與收件人表的大小相同。 每位客戶有一筆記錄。
  • large-size​表與Broad日誌表類似。 每個客戶有許多記錄。
    例如，如果您的資料庫包含1000萬個收件者，則「廣泛」日誌表包含約1億到2億條消息，而「傳送」表包含幾千條記錄。

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

列數也會影響效能。 Adobe Campaign資料庫的設計目的並非儲存未用於鎖定目標或個人化目的的歷史資料 — 這是一個運作資料庫。

要防止與高行數相關的任何效能問題，請僅在資料庫中保留必要的記錄。 任何其他記錄應匯出至協力廠商資料倉庫，並從Adobe Campaign作業資料庫中移除。

以下是一些關於表格大小的最佳實務：

  • 設計欄位更少、數字資料更多的大型表。
  • 請勿使用大量的欄類型(例如：Int64)，儲存小數字（如布林值）。
  • 從表定義中刪除未使用的列。
  • 請勿在Adobe Campaign資料庫中保留歷史或非作用中資料（匯出和清除）。

以下是範例：

在此範例中：

  • 事務​和​事務項​表很大：一千多萬。
  • Product​和​Store​表較小：少於一萬。
  • 產品標籤和參考已放置在​Product​表中。
  • 事務項​表只具有指向​產品​表的連結，該表是數字的。

本頁內容