Blog · 14 września 2023 · Steve Simpson · Architektura danych

Modelowanie danych ze Steve’em: od list wyboru do nieskończoności i dalej

Wprowadzenie:

Witaj w kolejnej sesji serii Steve’a o modelowaniu danych! W tym wpisie przyjrzymy się wszechstronnemu zastosowaniu list wyboru i omówimy sytuacje, w których przy bardziej zaawansowanych wymaganiach modelowania danych warto rozważyć alternatywy.

Listy wyboru

Listy wyboru są idealne, gdy pole wymaga zestawu stałych wartości. Dają czyste doświadczenie użytkownika, ale mają pewne ograniczenia:

Do dodawania wartości potrzebne są podwyższone uprawnienia administratora.
Nowe wartości trzeba wdrażać przez sandboxy.

Błędy walidacji danych pojawiają się, jeśli wartości z integracji zewnętrznych nie zostały wcześniej dodane w Salesforce.

Opcje dla list wyboru

Oto kilka opcji do rozważenia:

Opcja 1: globalne zestawy wartości

To standardowa opcja Salesforce, która pozwala korzystać z tych samych list w wielu obiektach.

Opcja 1, listy wyboru i globalne zestawy wartości. Zaleta: czyste doświadczenie użytkownika. Wady: wartości musi dodawać administrator, zmiany trzeba wdrażać do sandboxów, systemy zewnętrzne sprawiają problemy, a wartość nie może mieć powiązanych pól

Globalne zestawy wartości najlepiej sprawdzają się dla wartości używanych w wielu miejscach. Na przykład możesz mieć dwa globalne zestawy wartości, „pipe size” i „pipe thickness”, dające użytkownikom czysty interfejs wyboru wartości.

[caption id="" align=“alignnone” width=“1372”] Przykładowe zestawy wartości [/caption] [caption id="" align=“alignnone” width=“1814”] Przykładowe wartości [/caption] [caption id="" align=“alignnone” width=“676”] Wybór z listy [/caption]

Opcja 2: pola tekstowe

To po prostu pole tekstowe bez walidacji.

Opcja 2, pola tekstowe. Zaleta: przyjmują dowolną wartość. Wady: brak walidacji danych i słabe doświadczenie użytkownika

Jeśli wartości danych przychodzą przez integracje, możesz rozważyć pola tekstowe. To podejście traci jednak walidację i pozwala użytkownikom wpisywać dowolne dane, co może prowadzić do niespójności.

To może być opcja, jeśli pola są w Salesforce tylko do odczytu i jedynie wyświetlasz wartości.

[caption id="" align=“alignnone” width=“678”] Brak walidacji [/caption]

Opcja 3: wspólny obiekt referencyjny

Opcja 3, wspólny obiekt referencyjny z typami rekordów i lookupami filtrowanymi według typu rekordu. Zalety: dane dodawane dynamicznie i kilka powiązanych pól. Wady: import danych do sandboxów, a obiekt źródłowy przechowuje klucz zamiast wartości

Do importu danych można użyć wspólnego obiektu referencyjnego z wieloma typami rekordów. To podejście tworzy dwa lookupy na obiekcie głównym, wskazujące na obiekt referencyjny zamiast na rzeczywiste wartości. Możesz też dynamicznie dodawać nowe wartości bez uprawnień administratora, co zwiększa elastyczność.

[caption id="" align=“alignnone” width=“1462”] Użycie typów rekordów [/caption] [caption id="" align=“alignnone” width=“1700”] Użyj filtrowanego lookupu [/caption] [caption id="" align=“alignnone” width=“1434”] Dodawanie wartości [/caption] [caption id="" align=“alignnone” width=“658”] Jak wygląda wybór wartości. Sortowanie nie jest poprawne, a przy pierwszym załadowaniu nie widać wszystkich wartości; użytkownik musi ich szukać. Usuń też uprawnienie „Create” z profili i zestawów uprawnień, żeby użytkownicy nie tworzyli w locie kolejnych rekordów. [/caption]

Część 3: opcje zaawansowane

W bardziej zaawansowanych scenariuszach rozważ te opcje:

Opcja 4: niestandardowe ekrany z obiektem referencyjnym

Opcja 4, obiekt referencyjny plus pole tekstowe, z komponentem Lightning Web Component, który czyta wartości listy z obiektu referencyjnego. Zalety: dane dodawane dynamicznie, a obiekt źródłowy przechowuje wartości. Wada: wymaga programowania LWC i niestandardowych stron

Jeśli na ekranach edycji używasz niestandardowych komponentów Lightning Web Components (LWC), możesz użyć obiektu referencyjnego do odczytu i wyświetlania wartości, przechowując rzeczywiste wartości zamiast lookupów.

Opcja 5: samodzielne obiekty

Opcja 5, samodzielne obiekty referencyjne, po jednym na listę. Zalety: dane dodawane dynamicznie, czysty model danych i wiele powiązanych pól. Wady: import danych do sandboxów, klucze zamiast wartości i wiele obiektów

Jeśli wartości lookupu zyskują na znaczeniu, rozważ utworzenie samodzielnego obiektu dla każdej listy i osobnych lookupów. To podejście pozwala dynamicznie dodawać dane, utrzymuje czysty model danych i obsługuje dodatkowe powiązane pola na każdym obiekcie.

Praktyczne przykłady

Oto praktyczne przykłady ilustrujące każdą opcję:

Standardowe listy wyboru: czysty interfejs ze stałymi wartościami.

Pola tekstowe bez walidacji: elastyczność, ale bez walidacji danych.

Lookup do obiektów referencyjnych: ten sam obiekt z filtrowanymi typami rekordów dla elastyczności.

Samodzielne obiekty: osobne obiekty dla każdego lookupu, czysty i elastyczny model danych.

Podsumowanie

Zrozumienie niuansów list wyboru i ich alternatyw jest kluczowe dla skutecznego modelowania danych. Od standardowych list wyboru po samodzielne obiekty, każda opcja daje inne korzyści, dopasowane do konkretnych potrzeb modelowania danych.

Wróć wkrótce!

Więcej spostrzeżeń i wskazówek znajdziesz tutaj, na www.SteveTechArc.com, i na kanale YouTube @SteveTechArc (opens in a new tab). Zasubskrybuj i rozwijaj z nami swój talent do modelowania danych!

Pomagam zmieniać świat, dzieląc się ciekawymi przemyśleniami z innymi architektami i z tymi, którzy są na drodze do architektury!

Transkrypcję wspomagała AI

STA 2.2