資料模型最佳實務 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表格的實體主索引鍵。 若為內建表格，則為通用唯一ID (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 中的內建記錄表有預先設定的保留期間，通常將其資料儲存時間限制在六個月或更短時間。
以下是內建表格的預設保留值。請注意，保留設定是由 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」等操作。 如果您知道預期結果並想要篩選，請套用包含「等於」或其他特定篩選運運算元的相同條件。
- 請嘗試並確保匯入和匯出等程式在工作時間進行。
- 請確定所有日常活動都有排程，並遵守排程。
- 如果有一或數個每日處理作業失敗，且必須在同一天執行，請確定啟動手動處理作業時沒有衝突處理作業在執行，因為這會影響系統效能。
- 確保在匯入程式期間或執行任何手動程式時，不會執行任何每日行銷活動。
- 使用一或多個參考表格，而不是在每一列複製欄位。 使用索引鍵/值配對時，最好選擇數字索引鍵。
- 簡短的字串仍可接受。 如果外部系統中已有參考表格，重複使用相同表格將促進與Adobe Campaign的資料整合。
一對多關係 one-to-many-relationships
- 資料設計會影響可用性和功能。 如果您在設計資料模型時有許多一對多關係，這會讓使用者更難以在應用程式中建構有意義的邏輯。 非技術行銷人員可能很難正確建構和瞭解一對多篩選器邏輯。
- 將所有重要欄位放在一個表格中很好，因為這樣使用者更容易建立查詢。 有時候，如果可以避免聯結，跨表格複製某些欄位對效能也有好處。
- 某些內建功能無法參考一對多關係，例如「優惠加權」公式和「傳送」。
大型表格 large-tables
Adobe Campaign仰賴協力廠商資料庫引擎。 視提供者而定，為大型表格最佳化效能可能需要特定設計。
以下是使用大型表格和複雜聯結設計資料模型時應遵循的一些常見最佳實務。
- 使用其他自訂收件者表格時，請確定您對每個傳遞對應都有專屬的記錄表格。
- 減少欄數，特別是識別未使用的欄。
- 藉由避免複雜的聯結（例如多個條件和/或數個欄上的聯結）來最佳化資料模型關係。
- 對於聯結索引鍵，您可以使用數值或字串型值。
- 儘可能減少記錄保留的深度。 如果您需要更深入的記錄，您可以彙總計算和/或處理自訂記錄表，以儲存更大的記錄。
表格的大小 size-of-tables
表格大小是記錄數和每筆記錄欄數的組合。 兩者都會影響查詢的效能。
- 小型 資料表與傳遞資料表類似。
- 中等大小 資料表與收件者資料表的大小相同。 每個客戶有一筆記錄。
- 大型 資料表類似於Broad記錄資料表。 每個客戶有許多記錄。
例如，如果您的資料庫包含1千萬位收件者，則廣泛記錄表格會包含約1億到2億則訊息，而傳遞表格則會包含數千筆記錄。
列數也會影響效能。 Adobe Campaign資料庫的設計目的，並非儲存主動未用於目標定位或個人化用途的歷史資料，而是儲存運作資料庫。
若要避免出現任何與大量資料列相關的效能問題，只需將必要的記錄保留在資料庫中。 任何其他記錄應匯出至協力廠商資料倉儲，並從Adobe Campaign作業資料庫中移除。
以下是有關表格大小的一些最佳實務：
- 設計欄位較少且數值資料較多的大型表格。
- 請勿使用大數字型別的欄來儲存小數字，如布林值。
- 從表格定義中移除未使用的欄。
- 請勿在Adobe Campaign資料庫中保留歷史資料或非作用中資料（匯出和清理）。