God praxis för datamodell data-model-best-practices
I det här dokumentet beskrivs viktiga rekommendationer när du utformar din Adobe Campaign-datamodell.
Om du vill ha en bättre förståelse för de inbyggda tabellerna i Campaign och deras interaktion kan du läsa det här avsnittet.
Läs den här dokumentationen för att komma igång med kampanjscheman. Lär dig hur du konfigurerar tilläggsscheman för att utöka Adobe Campaign-databasens konceptuella datamodell i det här dokumentet.
Översikt overview
Adobe Campaign-systemet är extremt flexibelt och kan byggas ut utöver den ursprungliga implementeringen. Men även om möjligheterna är oändliga är det viktigt att fatta kloka beslut och bygga starka grunder för att börja utforma din datamodell.
Det här dokumentet innehåller vanliga användningsexempel och metodtips om hur du kan skapa rätt Adobe Campaign-verktyg.
Datamodellarkitektur data-model-architecture
Adobe Campaign är ett kraftfullt kanalövergripande kampanjhanteringssystem som kan hjälpa er att anpassa era online- och offlinestrategier för att skapa personaliserade kundupplevelser.
Kundfokuserat tillvägagångssätt customer-centric-approach
De flesta e-postleverantörer kommunicerar med kunderna via en listcentrerad strategi, men Adobe Campaign förlitar sig på en relationsdatabas för att få en bredare bild av kunderna och deras attribut.
Detta kundcentrerade tillvägagångssätt visas i tabellen nedan. Tabellen Mottagare i grått representerar huvudkundtabellen som allting byggs runt:
Gå till Admin > Configuration > Data schemas, markera en resurs i listan och klicka på fliken Documentation om du vill komma åt beskrivningen av varje tabell.
Adobe Campaign standarddatamodell presenteras i det här dokumentet.
Data för Adobe Campaign data-for-campaign
Vilka data ska skickas till Adobe Campaign? Det är viktigt att kunna avgöra vilka data som krävs för era marknadsföringsaktiviteter.
Om du vill avgöra om ett attribut behövs eller inte i Adobe Campaign, frågar du dig själv om det skulle ingå i någon av dessa kategorier:
- Attribut som används för segmentering
- Attribut som används för datahanteringsprocesser (t.ex. aggregerad beräkning)
- Attribut som används för personalisering
Om du inte hamnar i något av dessa behöver du troligen inte det här attributet i Adobe Campaign.
Val av datatyper data-types
Följ de bästa metoderna nedan för att konfigurera data i Adobe Campaign för att säkerställa att din systemarkitektur och prestanda är bra.
- En stor tabell ska i de flesta fall ha numeriska fält och innehålla länkar till referenstabeller (när du arbetar med värdelista).
- Med attributet expr kan du definiera ett schemaattribut som ett beräknat fält i stället för ett fysiskt uppsättningsvärde i en tabell. Detta gör att du kan komma åt information i ett annat format (till exempel ålder och födelsedatum) utan att behöva lagra båda värdena. Detta är ett bra sätt att undvika att duplicera fält. I mottagartabellen används till exempel ett uttryck för domänen, som redan finns i e-postfältet.
- Men om uttrycksberäkningen är komplex bör du inte använda attributet expr eftersom beräkningen kan påverka frågeprestanda.
- Typen XML är ett bra sätt att undvika att skapa för många fält. Men det tar också upp diskutrymme när en CLOB-kolumn används i databasen. Det kan även leda till komplexa SQL-frågor och kan påverka prestanda.
- Längden för ett string-fält ska alltid definieras med kolumnen. Som standard är maxlängden i Adobe Campaign 255, men Adobe rekommenderar att du håller fältet kortare om du redan vet att storleken inte kommer att överskrida en kortare längd.
- Det går bra att ha ett fält som är kortare i Adobe Campaign än i källsystemet om du är säker på att storleken i källsystemet var för stor och inte skulle nås. Detta kan betyda en kortare sträng eller ett mindre heltal i Adobe Campaign.
Val av fält choice-of-fields
Ett fält måste lagras i en tabell om det har ett syfte att målinrikta eller personalisera. Det innebär att om ett fält inte används för att skicka ett anpassat e-postmeddelande eller används som ett kriterium i en fråga tar det upp diskutrymme medan det är oanvändbart.
För hybridinstanser och lokala instanser täcker FDA (Federated Data Access, en valfri funktion som ger åtkomst till externa data) behovet av att lägga till ett fält"direkt" under en kampanjprocess. Du behöver inte importera allt om du har FDA. Mer information finns i Om åtkomst till federerade data.
Val av nycklar choice-of-keys
Utöver autopk som är definierad som standard i de flesta tabeller bör du lägga till några logiska nycklar eller affärsnycklar (kontonummer, klientnummer osv.). Den kan användas senare för import/avstämning eller datapaket. Mer information finns i Identifierare.
Effektiva nycklar är viktiga för prestanda. Numeriska datatyper bör alltid vara att föredra som nycklar för tabeller.
För SQLServer-databasen kan du använda "grupperat index" om prestanda behövs. Eftersom Adobe inte hanterar detta måste du skapa det i SQL.
Dedikerade tabellutrymmen dedicated-tablespaces
Med tabellutrymmesattributet i schemat kan du ange ett dedikerat tabellutrymme för en tabell.
Med installationsguiden kan du lagra objekt efter typ (data, tillfällig och indexerad).
Dedikerade tabellutrymmen är bättre för partitionering, säkerhetsregler och ger smidig och flexibel administration, bättre optimering och prestanda.
Identifierare identifiers
Adobe Campaign-resurser har tre identifierare och det går att lägga till ytterligare en identifierare.
I följande tabell beskrivs dessa identifierare och deras syfte.
- ID är den fysiska primärnyckeln för en Adobe Campaign-tabell. För färdiga tabeller är det ett genererat 32-bitarsnummer från en sekvens
- Den här identifieraren är vanligtvis unik för en viss Adobe Campaign-instans.
- Ett automatiskt genererat ID kan vara synligt i en schemadefinition. Sök efter attributet autopk="true".
- Automatiskt genererade identifierare bör inte användas som referens i ett arbetsflöde eller i en paketdefinition.
- Man bör inte anta att ID:t alltid kommer att vara ett ökande tal.
- ID:t i en körklar tabell är ett 32-bitars tal och den här typen bör inte ändras. Numret hämtas från en sekvens som beskrivs i avsnittet med samma namn.
- Den här informationen är en unik identifierare för en post i en tabell. Värdet kan uppdateras manuellt, vanligtvis med ett genererat namn.
- Den här identifieraren behåller sitt värde när den distribueras i en annan instans av Adobe Campaign och får inte vara tom.
- Byt namn på den post som genererats av Adobe Campaign om objektet ska distribueras från en miljö till en annan.
- När ett objekt har ett namnutrymmesattribut (schema till exempel), kommer detta gemensamma namnutrymme att utnyttjas för alla anpassade objekt som skapas. Vissa reserverade namnutrymmen bör inte användas: nms, xtk, nl, ncl, crm, xxl.
- När ett objekt inte har något namnutrymme (workflow eller delivery till exempel) läggs det här namnutrymmesbegreppet till som ett prefix för ett internt namnobjekt: namespaceMyObjectName.
- Använd inte specialtecken som blanksteg", semikolon ":" eller bindestreck "-". Alla dessa tecken ersätts med understrecket"_" (tillåtet tecken). "abc-def" och "abc:def" skulle till exempel lagras som "abc_def" och skrivas över varandra.
- Etiketten är ett företags-ID eller en post i Adobe Campaign.
- Det här objektet tillåter mellanslag och specialtecken.
- Det garanterar inte att ett register är unikt.
- Du bör bestämma en struktur för objektetiketterna.
- Detta är den mest användarvänliga lösningen för att identifiera en post eller ett objekt för en Adobe Campaign-användare.
Anpassade interna nycklar custom-internal-keys
Primärnycklar krävs för alla tabeller som skapas i Adobe Campaign.
De flesta organisationer importerar poster från externa system. Även om den fysiska nyckeln för mottagartabellen är attributet "id", är det möjligt att fastställa en anpassad nyckel dessutom.
Denna anpassade nyckel är den faktiska primärnyckeln för posten i det externa system som matar Adobe Campaign.
När en körklar tabell har både en autopk och en intern nyckel, ställs den interna nyckeln in som ett unikt index i den fysiska databastabellen.
När du skapar en anpassad tabell finns det två alternativ:
- En kombination av autogenererad nyckel (id) och intern nyckel (anpassad). Det här alternativet är intressant om systemnyckeln är en sammansatt nyckel eller inte ett heltal. Heltal ger högre prestanda i stora tabeller och att de kopplas ihop med andra tabeller.
- Använda primärnyckeln som extern systemprimärnyckel. Den här lösningen är vanligtvis att föredra eftersom den förenklar import och export av data, med en konsekvent nyckel mellan olika system. Automatisk opk ska inaktiveras om nyckeln heter"id" och förväntas fyllas med externa värden (inte autogenererade).
Sekvenser sequences
Adobe Campaign primärnyckel är ett automatiskt genererat ID för alla körklara tabeller och kan vara samma för anpassade tabeller. Mer information finns i det här avsnittet.
Det här värdet hämtas från vad som kallas sequence, som är ett databasobjekt som används för att generera en nummersekvens.
Det finns två typer av sekvenser:
- Delad: fler än en tabell skulle välja sitt ID från samma sekvens. Det innebär att om ett ID 'X' används av en tabell, så har ingen annan tabell som delar samma sekvens en post med ID 'X'. XtkNewId är standardsekvensen som är tillgänglig i Adobe Campaign.
- Dedikerad: endast en tabell plockar sina ID:n från sekvensen. Sekvensnamnet innehåller vanligtvis tabellnamnet.
Därför skulle en kund som skickar 6 miljarder e-postmeddelanden årligen med en kvarhållningsperiod på 180 dagar för sina loggar få slut på ID:n på 4 månader. Om du vill förhindra en sådan utmaning måste du se till att du har rensningsinställningar för volymerna. Mer information finns i det här avsnittet.
När en anpassad tabell skapas i Adobe Campaign med en primärnyckel som autoPK, bör en anpassad dedikerad sekvens systematiskt kopplas till den tabellen.
Som standard har en anpassad sekvens värden mellan +1 000 och +2,1BB. Tekniskt sett är det möjligt att få ett fullständigt urval av 4BB genom att aktivera negativa ID:n. Detta bör användas med försiktighet och ett ID kommer att förloras vid övergång från negativa till positiva tal: posten 0 ignoreras vanligtvis av Adobe Campaign i genererade SQL-frågor.
Titta på den här videon om du vill ha mer information om sekvensslut.
Index indexes
Index är viktiga för prestandan. När du deklarerar en nyckel i schemat skapas ett index automatiskt i nyckelfälten i Adobe. Du kan också deklarera fler index för frågor som inte använder nyckeln.
Adobe rekommenderar att du definierar ytterligare index eftersom det kan förbättra prestandan.
Tänk dock på följande:
- Indexanvändningen är bunden till ditt åtkomstmönster. Optimering av indexering är ofta en viktig del i databasdesignen och måste hanteras av experter. Att lägga till index är ofta ett iterativt arbetsflöde som är kopplat till databasunderhåll. Det görs med tiden, steg för steg, för att åtgärda prestandaproblem när det händer.
- Index ökar den totala tabellstorleken (för att lagra själva indexet).
- Genom att lägga till index i kolumner kan du förbättra prestanda för dataläsåtkomst (SELECT), men det kan minska prestanda för dataskrivåtkomst (UPDATE).
- Eftersom detta påverkar prestandan under infogningen av data bör indexens storlek och antal begränsas.
- Lägg inte till index när det inte är nödvändigt. Kontrollera att det är obligatoriskt och det ökar den övergripande prestandan för dina frågor (testa och lär).
- I allmänhet är ett index effektivt om du vet att dina frågor inte återför mer än 10 % av posterna.
- Välj noggrant de index som behöver definieras.
- Ta inte bort interna index från färdiga tabeller.
Exempel
Det kan bli mycket komplicerat att hantera index, och det är därför viktigt att förstå hur de fungerar. För att illustrera denna komplexitet kan vi ta ett grundläggande exempel, som att söka efter mottagare genom att filtrera på förnamn och efternamn. Så här gör du:
-
Gå till mappen som visar alla mottagare i databasen. Mer information finns i Hantera profiler.
-
Högerklicka på fältet First name.
-
Välj Filter on this field.
-
Upprepa den här åtgärden för fältet Last name.
De två motsvarande filtren läggs till ovanpå skärmen.
Nu kan du utföra sökfiltrering i fälten First name och Last name enligt de olika filtervillkoren.
Nu kan du lägga till index för att snabba upp sökningen efter dessa filter. Men vilka index ska användas?
Tabellen nedan visar i vilka fall de tre index som beskrivs nedan används eller inte enligt det åtkomstmönster som visas i den första kolumnen.
Länkar och kardinalitet links-and-cardinality
Länkar links
Se upp för den"egna" integriteten i stora tabeller. Om du tar bort poster som har breda tabeller i "egen" integritet kan instansen stoppas. Tabellen är låst och borttagningarna görs en i taget. Därför är det bäst att använda"neutral" integritet i underordnade tabeller som har stora volymer.
Att deklarera en länk som en extern koppling är inte bra för prestandan. Posten med noll-id emulerar den externa kopplingsfunktionen. Du behöver inte deklarera externa kopplingar om autopk används i länken.
Även om det är möjligt att ansluta en tabell i ett arbetsflöde rekommenderar Adobe att du definierar gemensamma länkar mellan resurser direkt i datastrukturdefinitionen.
Länken ska definieras i enlighet med de data som finns i tabellerna. En felaktig definition kan påverka data som hämtas via länkar, t.ex. oväntat duplicering av poster.
Namnge länken konsekvent med tabellnamnet: länknamnet bör hjälpa till att förstå vad den distinkta tabellen är.
Namnge inte en länk med ID som suffix. Ge det till exempel namnet"transaktion" i stället för"transaktionId".
Som standard skapar Adobe Campaign en länk med den externa tabellens primärnyckel. För större tydlighet är det bättre att uttryckligen definiera kopplingen i länkdefinitionen.
Ett index läggs till i de attribut som används i en länk.
The länkar skapade av och senast ändrade av finns i många tabeller. Det går att inaktivera indexet genom att använda attributet noDbIndex på länken, om den här informationen inte används av företaget.
Kardinalitet cardinality
När du utformar en länk måste du se till att målposten är unik när en 1-1-relation har deklarerats. Annars kan join returnera flera poster när bara en förväntas. Detta resulterar i fel under leveransförberedelsen när frågan returnerar fler rader än förväntat. Ange länknamnet till samma namn som målschemat.
Definiera en länk med en kardinalitet (1-N) i schemat på (1) sidan. Relationen mottagare (1) - (N)-transaktion ska till exempel definieras i transaktionsschemat.
Observera att en länks omvända kardinalitet är (N) som standard. Det går att definiera en länk (1-1) genom att lägga till attributet revCardinality='single' till länkdefinitionen.
Om den omvända länken inte ska vara synlig för användaren kan du dölja den med länkdefinitionen revLink=NONE. Ett bra exempel för detta är att definiera en länk från mottagaren till den senast slutförda transaktionen. Du behöver bara se länken från mottagaren till den sista transaktionen och ingen omvänd länk krävs för att kunna visas från transaktionsregistret.
Länkar som utför en extern koppling (1-0…1) bör användas med försiktighet eftersom det påverkar systemets prestanda.
Datalagring - rensning och rensning data-retention
Adobe Campaign är varken ett datalager eller ett rapportverktyg. För att Adobe Campaign-lösningen ska fungera väl bör databastillväxten därför förbli under kontroll. För att uppnå detta kan det vara bra att följa några av de bästa metoderna nedan.
Som standard har Adobe Campaign leverans- och spårningsloggar en kvarhållningstid på 180 dagar. En rensningsprocess körs för att ta bort alla äldre loggar.
- Om du vill att loggarna ska sparas längre bör detta beslut fattas med stor noggrannhet beroende på databasstorleken och mängden meddelanden som skickas. Som påminnelse är Adobe Campaign-sekvensen ett 32-bitars heltal.
- Vi rekommenderar att du inte har mer än 1 miljard poster samtidigt i dessa tabeller (cirka 50 % av de 2,14 miljarder ID som finns) för att begränsa riskerna med att använda alla tillgängliga ID:n. Detta kräver att vissa kunder minskar kvarhållningstiden till mindre än 180 dagar.
Läs mer om datalagring i Riktlinjer för sekretess och säkerhet för kampanjer.
Läs mer om rensningsarbetsflödet för Campaign-databasen i det här avsnittet.
Det finns några lösningar som minimerar behovet av arkivering i Adobe Campaign:
- Exportera data i ett datalager utanför Adobe Campaign.
- Generera aggregerade värden som använder mindre utrymme samtidigt som de är tillräckliga för er marknadsföringspraxis. Du behöver t.ex. inte den fullständiga kundtransaktionshistoriken i Adobe Campaign för att hålla reda på de senaste köpen.
Du kan deklarera attributet "deleteStatus" i ett schema. Det är effektivare att markera posten som borttagen och sedan skjuta upp borttagningen i rensningsaktiviteten.
Prestanda performance
Följ de bästa metoderna nedan för att få bättre prestanda när som helst.
Allmänna rekommendationer general-recommendations
- Undvik åtgärder som "CONTAINS" i frågor. Om du vet vad som förväntas och vill filtreras efter använder du samma villkor med "EQUAL TO" eller andra specifika filteroperatorer.
- Undvik koppling till icke-indexerade fält när du skapar data i arbetsflöden.
- Försök att se till att processer som import och export går utanför kontorstid.
- Se till att det finns ett schema för alla dagliga aktiviteter och att schemat följs.
- Om en eller flera av de dagliga processerna misslyckas och om det är obligatoriskt att köra den samma dag, ska du se till att det inte finns några processkonflikter som körs när den manuella processen startar, eftersom detta kan påverka systemets prestanda.
- Kontrollera att ingen av de dagliga kampanjerna körs under importprocessen eller när någon manuell process körs.
- Använd en eller flera referenstabeller i stället för att duplicera ett fält i varje rad. När du använder nyckel/värde-par bör du välja en numerisk nyckel.
- En kort sträng kan fortfarande användas. Om referenstabeller redan finns på plats i ett externt system, kommer dataintegreringen med Adobe Campaign att underlättas om du återanvänder samma.
En-till-många-relationer one-to-many-relationships
- Datadesign påverkar användbarhet och funktionalitet. Om du utformar din datamodell med många en-till-många-relationer blir det svårare för användarna att skapa meningsfull logik i programmet. En-till-många-filterlogik kan vara svår för icke-tekniska marknadsförare att konstruera och förstå på ett korrekt sätt.
- Det är bra att ha alla viktiga fält i en tabell eftersom det gör det enklare för användarna att skapa frågor. Ibland kan det också vara bra för prestanda att duplicera vissa fält mellan tabeller om det kan undvika en koppling.
- Vissa inbyggda funktioner kan inte referera till 1:N-relationer, t.ex. offertviktningsformel och Leveranser.
Stora tabeller large-tables
Adobe Campaign förlitar sig på databasmotorer från tredje part. Beroende på vilken provider som används kan optimering av prestanda för större tabeller kräva en viss design.
Nedan följer några vanliga metodtips som bör följas när du utformar din datamodell med stora tabeller och komplexa sammanfogningar.
- När du använder ytterligare anpassade mottagartabeller måste du ha en dedikerad loggtabell för varje leveransmappning.
- Minska antalet kolumner, särskilt genom att identifiera de som inte används.
- Optimera datamodellens relationer genom att undvika komplexa kopplingar, till exempel kopplingar på flera villkor och/eller flera kolumner.
- Använd alltid numeriska data i stället för teckensträngar för kopplingsnycklar.
- Minska så mycket du kan av djupet för loggbevarande. Om du behöver mer detaljerad historik kan du sammanställa beräkningar och/eller hantera anpassade loggtabeller för att lagra större historik.
Tabellstorlek size-of-tables
Tabellstorleken är en kombination av antalet poster och antalet kolumner per post. Båda kan påverka prestanda för frågor.
- En liten-tabell liknar leveranstabellen.
- En tabell med storleken medel är samma som storleken på mottagartabellen. Det finns en post per kund.
- En stor-tabell liknar den stora loggtabellen. Det finns många poster per kund.
Om din databas till exempel innehåller 10 miljoner mottagare innehåller den stora loggtabellen cirka 100 till 200 miljoner meddelanden och leveranstabellen innehåller några tusen poster.
I PostgreSQL får en rad inte överskrida 8 kB för att undvika TOAST-mekanismen. Försök därför att så mycket som möjligt minska antalet kolumner och storleken på varje rad för att behålla optimala prestanda för systemet (minne och processor).
Antalet rader påverkar även prestandan. Adobe Campaign-databasen är inte utformad för att lagra historiska data som inte aktivt används för målinriktning eller personalisering - det här är en operativ databas.
Om du vill förhindra prestandaproblem som har att göra med det stora antalet rader sparar du bara de nödvändiga posterna i databasen. Alla andra poster bör exporteras till ett datalager från tredje part och tas bort från Adobe Campaign databas.
Här följer några tips om tabellstorlek:
- Designa stora tabeller med färre fält och mer numeriska data.
- Använd inte en stor kolumntyp (t.ex. Int64) för att lagra små tal som booleska värden.
- Ta bort oanvända kolumner från tabelldefinitionen.
- Spara inte historiska eller inaktiva data i Adobe Campaign-databasen (export och rensning).
Här är ett exempel:
I detta exempel:
- Tabellerna Transaktion och Transaktionsobjekt är stora: mer än 10 miljoner.
- Tabellerna Produkt och Butik är mindre: mindre än 10 000.
- Produktetiketten och referensen har placerats i tabellen Produkt.
- Tabellen Transaktionsobjekt har bara en länk till tabellen Produkt som är numerisk.