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

Steve Data Modeling: от списков выбора — к бесконечности и дальше

Введение:

Добро пожаловать в новый познавательный выпуск о моделировании данных в серии Steve’s Data Modeling! В этой статье мы рассмотрим разнообразные способы применения списков выбора и обсудим ситуации, в которых для более сложных требований к модели данных стоит подумать об альтернативах.

Что такое списки выбора

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

Для добавления значений нужны расширенные права администратора.
Новые значения нужно развертывать через песочницы.

Если значения из сторонних интеграций заранее не добавлены в Salesforce, возникают ошибки проверки данных.

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

Вот несколько вариантов, которые стоит рассмотреть:

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

Это стандартный вариант Salesforce, и один список можно использовать в разных объектах.

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

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

[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), которые ссылаются на справочный объект, а не на сами значения. Кроме того, новые значения можно добавлять динамически без прав администратора, что повышает гибкость.

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

Раздел 3: продвинутые варианты

Для более сложных сценариев рассмотрите такие варианты:

Вариант 4: пользовательские экраны со справочным объектом

Вариант 4: справочный объект плюс текстовое поле и компонент Lightning Web, который читает значения списка выбора из справочного объекта. Преимущества: данные добавляются динамически, а исходный объект хранит сами значения. Недостаток: нужна разработка LWC и пользовательские страницы

Если для экранов редактирования вы используете пользовательские компоненты Lightning Web (LWC), можно читать и отображать значения из справочного объекта, а сохранять сами значения вместо полей подстановки.

Вариант 5: отдельные объекты

Вариант 5: отдельные справочные объекты, по одному на список. Преимущества: данные добавляются динамически, чистая модель данных и много связанных полей. Недостатки: загрузка данных в песочницы, ключи вместо значений и много объектов

Если значения подстановки становятся все важнее, подумайте о создании отдельного объекта для каждого из них и отдельных полей подстановки. Такой подход позволяет добавлять данные динамически, сохраняет модель данных чистой и поддерживает дополнительные связанные поля в каждом объекте.

Практические примеры

Вот практические примеры для каждого варианта:

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

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

Подстановка на справочные объекты: Один и тот же объект с отфильтрованными типами записей для гибкости.

Отдельные объекты: Отдельный объект для каждой подстановки, что дает чистую и гибкую модель данных.

Заключение

Понимание нюансов списков выбора и их альтернатив крайне важно для эффективного моделирования данных. От стандартных списков выбора до отдельных объектов — у каждого варианта свои преимущества для конкретных задач моделирования данных.

Возвращайтесь скорее!

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

Помогаем менять мир, делясь интересными мыслями с коллегами-архитекторами и теми, кто идет по пути к профессии архитектора!

Расшифровка сделана с помощью ИИ

STA 2.2