Блог · 14 вересня 2023 р. · Steve Simpson · Архітектура даних

Моделювання даних зі Steve: від списків вибору до безмежності й далі

Вступ:

Ласкаво просимо до ще одного корисного заняття з моделювання даних у серії Steve’s Data Modeling! У цьому блозі ми дослідимо різноманітне використання списків вибору й обговоримо сценарії, де для складніших вимог моделювання даних варто розглянути альтернативи.

Розуміння списків вибору

Списки вибору ідеальні, коли поле потребує набору фіксованих значень. Вони дають чистий досвід користувача, але мають певні обмеження:

Щоб додавати значення, потрібні розширені права адміністратора.
Нові значення треба розгортати через sandbox.

Якщо значення від сторонніх інтеграцій заздалегідь не додали в Salesforce, виникають помилки перевірки даних.

Варіанти списків вибору

Ось кілька варіантів, які варто розглянути:

Варіант 1: глобальні набори значень

Це стандартний варіант Salesforce, що дає змогу використовувати списки в різних об’єктах.

Варіант 1, списки вибору й глобальні набори значень. Перевага: чистий досвід користувача. Недоліки: значення має додавати адміністратор, зміни треба розгортати в sandbox, зовнішні системи створюють проблеми, а значення не може мати пов’язаних полів

Глобальні набори значень найкраще підходять для значень, що використовуються в кількох місцях. Наприклад, можна мати два глобальні набори значень для «розміру труби» і «товщини труби», що дає користувачам чистий інтерфейс для вибору значень.

[caption id="" align=“alignnone” width=“1372”] Приклад наборів значень [/caption] [caption id="" align=“alignnone” width=“1814”] Приклад значень [/caption] [caption id="" align=“alignnone” width=“676”] Вибір зі списку [/caption]

Варіант 2: текстові поля

Це просто текстове поле без перевірки.

Варіант 2, текстові поля. Перевага: приймають будь-яке значення. Недоліки: немає перевірки даних і поганий досвід користувача

Якщо значення даних надходять через інтеграції, можна розглянути текстові поля. Однак за такого підходу втрачається перевірка: користувачі можуть вводити будь-які дані, що може призвести до неузгодженості.

Це може бути варіантом, якщо поля в Salesforce лише для читання і ви просто показуєте значення.

[caption id="" align=“alignnone” width=“678”] Без перевірки [/caption]

Варіант 3: спільний довідковий об’єкт

Варіант 3, спільний довідковий об’єкт із типами записів і lookup, відфільтрованими за типом запису. Переваги: дані додаються динамічно і є кілька пов’язаних полів. Недоліки: завантаження даних у sandbox, а вихідний об’єкт зберігає ключ, а не значення

Для завантаження даних можна використати спільний довідковий об’єкт із кількома типами записів. Такий підхід створює на основному об’єкті два lookup, що посилаються на довідковий об’єкт замість фактичних значень. Ви також можете додавати нові значення динамічно без прав адміністратора, що підвищує гнучкість.

[caption id="" align=“alignnone” width=“1462”] Використання типів записів [/caption] [caption id="" align=“alignnone” width=“1700”] Використовуйте відфільтрований lookup [/caption] [caption id="" align=“alignnone” width=“1434”] Додавання значень [/caption] [caption id="" align=“alignnone” width=“658”] Як виглядає вибір значення. Сортування неправильне, і під час першого завантаження показано не всі значення — користувачеві доводиться їх шукати. Також обов’язково приберіть «Create» з профілів і наборів дозволів, щоб користувачі не створювали нові записи на ходу. [/caption]

Розділ 3: розширені варіанти

Для складніших сценаріїв розгляньте такі варіанти:

Варіант 4: користувацькі екрани з довідковим об’єктом

Варіант 4, довідковий об’єкт плюс текстове поле з Lightning web component, що читає значення списку з довідкового об’єкта. Переваги: дані додаються динамічно, а вихідний об’єкт зберігає значення. Недолік: потрібна розробка LWC і користувацькі сторінки

Якщо для екранів редагування ви використовуєте користувацькі Lightning Web Components (LWC), можна застосувати довідковий об’єкт, щоб читати й показувати значення, зберігаючи фактичні значення замість lookup.

Варіант 5: окремі об’єкти

Варіант 5, окремі довідкові об’єкти, по одному на список. Переваги: дані додаються динамічно, чиста модель даних і багато пов’язаних полів. Недоліки: завантаження даних у sandbox, ключі замість значень і багато об’єктів

Якщо значення lookup стають важливішими, розгляньте створення окремого об’єкта для кожного і окремих lookup. Такий підхід дає змогу динамічно додавати дані, зберігає чисту модель даних і підтримує додаткові пов’язані поля в кожному об’єкті.

Практичні приклади

Ось практичні приклади для ілюстрації кожного варіанта:

Стандартні списки вибору: Чистий інтерфейс із фіксованими значеннями.

Текстові поля без перевірки: Гнучкість, але без перевірки даних.

Lookup на довідкові об’єкти: Той самий об’єкт із відфільтрованими типами записів для гнучкості.

Окремі об’єкти: Окремий об’єкт для кожного lookup — чиста й гнучка модель даних.

Висновок

Розуміння нюансів списків вибору та їхніх альтернатив критично важливе для ефективного моделювання даних. Від стандартних списків вибору до окремих об’єктів — кожен варіант має унікальні переваги для конкретних потреб моделювання даних.

Повертайтеся незабаром!

Більше думок і порад — тут, на www.SteveTechArc.com, і на YouTube-каналі @SteveTechArc (opens in a new tab). Підпишіться й розвивайте з нами майстерність моделювання даних!

Допомагаю змінювати світ, ділячись цікавими думками з колегами-архітекторами і тими, хто йде до архітектури!

Транскрипт оброблено за допомогою ШІ

STA 2.2