Blogg · 14 september 2023 · Steve Simpson · Dataarkitektur

Steve Data Modeling: från plocklistor till oändligheten och vidare

Introduktion:

Välkommen till ännu ett lärorikt avsnitt om datamodellering i serien Steve’s Data Modeling! I den här bloggen utforskar vi hur mångsidiga plocklistor är och diskuterar när du kan behöva överväga alternativ för mer avancerade krav på datamodellen.

Att förstå plocklistor

Plocklistor är perfekta när ett fält ska ha en uppsättning fasta värden. De ger en ren användarupplevelse men har vissa begränsningar:

Det krävs utökade administratörsrättigheter för att lägga till värden.
Nya värden måste driftsättas via sandboxar.

Det blir valideringsfel om värden från tredjepartsintegrationer inte har lagts in i Salesforce i förväg.

Alternativ för plocklistor

Här är några alternativ att överväga:

Alternativ 1: globala värdeuppsättningar

Det här är standardalternativet i Salesforce, och samma lista kan användas i flera objekt.

Alternativ 1, plocklistor och globala värdeuppsättningar. Fördel: en ren användarupplevelse. Nackdelar: en administratör måste lägga till värden, ändringar måste driftsättas till sandboxar, externa system ställer till problem, och ett värde kan inte ha relaterade fält

Globala värdeuppsättningar passar bäst för värden som används på flera ställen. Du kan till exempel ha två globala värdeuppsättningar för ”rördimension” och ”rörtjocklek”, som ger användarna ett rent gränssnitt för att välja värden.

[caption id="" align=“alignnone” width=“1372”] Exempel på värdeuppsättningar [/caption] [caption id="" align=“alignnone” width=“1814”] Exempel på värden [/caption] [caption id="" align=“alignnone” width=“676”] Välja från en lista [/caption]

Alternativ 2: textfält

Det här är bara ett textfält utan validering.

Alternativ 2, textfält. Fördel: de tar emot vilket värde som helst. Nackdelar: ingen datavalidering och en dålig användarupplevelse

Om datavärdena skickas in via integrationer kan du överväga textfält. Men då förlorar du valideringen, och användarna kan skriva in vad som helst, vilket kan leda till inkonsekvens.

Det kan vara ett alternativ om fälten är skrivskyddade i Salesforce och du bara visar värdena.

[caption id="" align=“alignnone” width=“678”] Ingen validering [/caption]

Alternativ 3: delat referensobjekt

Alternativ 3, ett delat referensobjekt med posttyper, med lookup-relationer filtrerade på posttyp. Fördelar: data läggs till dynamiskt och vissa relaterade fält. Nackdelar: dataladdningar i sandboxar, och källobjektet innehåller en nyckel i stället för värdet

Ett delat referensobjekt med flera posttyper kan användas för dataladdningar. Med det här upplägget skapar du två lookup-relationer på huvudobjektet som pekar på referensobjektet i stället för på de faktiska värdena. Du kan också lägga till nya värden dynamiskt utan administratörsrättigheter, vilket ger mer flexibilitet.

[caption id="" align=“alignnone” width=“1462”] Använda posttyper [/caption] [caption id="" align=“alignnone” width=“1700”] Använd en filtrerad lookup [/caption] [caption id="" align=“alignnone” width=“1434”] Lägga till värden [/caption] [caption id="" align=“alignnone” width=“658”] Så här ser det ut att välja ett värde. Sorteringen stämmer inte, och alla värden visas inte direkt vid inläsningen, användaren måste söka efter dem. Se också till att ta bort ”Skapa” från profiler och behörighetsuppsättningar så att användarna inte skapar fler poster i farten. [/caption]

Del 3: avancerade alternativ

För mer avancerade scenarier kan du överväga de här alternativen:

Alternativ 4: anpassade vyer med referensobjekt

Alternativ 4, ett referensobjekt plus ett textfält, med en Lightning-webbkomponent som läser plocklistans värden från referensobjektet. Fördelar: data läggs till dynamiskt och källobjektet behåller värdena. Nackdel: kräver LWC-utveckling och anpassade sidor

Om du använder anpassade Lightning-webbkomponenter (LWC:er) för dina redigeringsvyer kan du använda ett referensobjekt för att läsa in och visa värdena, och spara de faktiska värdena i stället för lookup-relationer.

Alternativ 5: fristående objekt

Alternativ 5, fristående referensobjekt, ett per lista. Fördelar: data läggs till dynamiskt, en ren datamodell och många relaterade fält. Nackdelar: dataladdningar i sandboxar, nycklar i stället för värden, och många objekt

Om uppslagsvärdena blir viktigare kan du överväga att skapa ett fristående objekt för vart och ett, med separata lookup-relationer. Det gör att data kan läggas till dynamiskt, håller datamodellen ren och ger plats för fler relaterade fält på varje objekt.

Praktiska exempel

Här är praktiska exempel som illustrerar varje alternativ:

Vanliga plocklistor: Ger ett rent gränssnitt med fasta värden.

Textfält utan validering: Ger flexibilitet men ingen datavalidering.

Lookup till referensobjekt: Använder samma objekt med filtrerade posttyper för flexibilitet.

Fristående objekt: Använder separata objekt för varje lookup, vilket ger en ren och flexibel datamodell.

Slutsats

Att förstå nyanserna i plocklistor och alternativen till dem är avgörande för en effektiv datamodellering. Från vanliga plocklistor till fristående objekt har varje alternativ sina egna fördelar för specifika behov i datamodellen.

Kom tillbaka snart!

För fler insikter och tips, håll utkik här på www.SteveTechArc.com och på YouTube-kanalen @SteveTechArc (opens in a new tab). Prenumerera och vässa din datamodellering tillsammans med oss!

Vi hjälper till att förändra världen genom att dela spännande tankar med andra arkitekter och med dem som är på väg att bli arkitekter!

Transkription med hjälp av AI

STA 2.2