Каждая структура — это обязательство
Также доступно на 28 языках
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Глава 3 курса Data Architect, Часть 1: Как стать архитектором данных. Назад: Моделирование данных ради смысла.
Вот вопрос, который я задаю на каждом занятии. Если кто-то говорит «я работаю с Salesforce», какое API-имя у объекта продукта?
Это Product2. Это моя первая лакмусовая бумажка. Когда-то Salesforce построил объект продукта, понял, что он не работает, и вынужден был оставить его позади. Просто убрать его было нельзя, поэтому добавили Product2. Даже Salesforce живет со своими старыми структурами.
А еще Salesforce оставил себе место для роста. Его стандартные объекты не имеют ни префикса, ни суффикса, и мы, люди, которые настраивают org, никогда не можем занять это пространство. Поэтому Salesforce может добавлять объекты и никогда не столкнется ни с чем из того, что строим мы.
Урок здесь такой: создание объекта занимает десять минут. Жить с ним — годы. Каждый объект и каждое поле, которые вы добавляете, — это обязательство. Они занимают хранилище. Они упираются в лимиты. Они получают модель общего доступа, проектировали вы ее или нет. Им нужна лицензия для каждого человека, который к ним прикасается. А теперь их читает и ИИ, так что то, как вы их называете и описываете, определяет, что агент поймет о ваших данных. Добавлять легко. Убирать трудно.
Эта глава превращает строительные блоки Salesforce в решения.
Изображение создано с помощью ИИ.
Структуры с первого взгляда
Заголовок раздела «Структуры с первого взгляда »Salesforce дает вам шесть мест для хранения данных. Я помещаю их на один слайд, потому что первая задача — знать, что все они существуют:
| Структура | Для чего | Подвох |
|---|---|---|
| Стандартные объекты | Собственная модель Salesforce: организация (Account), контакт, возможность, обращение, актив и остальные | Используйте их по назначению, иначе они будут с вами бороться |
| Пользовательские объекты | Ваши собственные бизнес-данные | Легко создать, трудно вывести из употребления |
| Внешние объекты | Данные, которые живут в другой системе и показываются в Salesforce | Каждое обращение — это вызов (callout) |
| Big objects | Огромные объемы, которые нужно хранить, но редко открывать | Нет стандартного интерфейса и отчетов; запросы идут через индекс |
| Файлы | Документы, фотографии и другой контент | Файловое хранилище быстро растет |
| Вложения | Старый способ хранить файлы | Устаревший: используйте Files |
Выбор структуры — только часть дела. До структуры идет вопрос, где данным вообще жить: в ядре (on core), по ссылке там, где они уже находятся, или в архиве.
Путь по этой главе
Заголовок раздела «Путь по этой главе »Глава большая, поэтому она состоит из десяти частей. Каждая самостоятельна. В главе 2 мы решили, какой должна быть модель; здесь мы решаем, как она должна жить в Salesforce.
- Платформа данных Salesforce: больше, чем база данных. Чем Salesforce отличается и почему у платформы есть форма.
- Смотрите на корабль-носитель: стандартные модели данных. Модели продаж и обслуживания, которые Salesforce уже построил, файлы, хранилище и персональные учетные записи.
- Постройте свое: пользовательские объекты. Что решает экран New Custom Object, поля, которые вы не создавали, и как читать любое API-имя: стандартное, пользовательское или из управляемого пакета.
- Где живут эти данные? В ядре, по ссылке или в архиве — решено до того, как создан хоть один объект.
- Выберите правильный объект. Тест на чистое соответствие, багаж, который приносят стандартные объекты, персональные учетные записи и лицензии, которые определяют, чем люди могут пользоваться.
- Поля — это тоже архитектура. Тип поля за типом поля, поведение, которое удивляет людей, и почему у каждого поля должно быть описание.
- У связей есть последствия. Lookup или master-detail, три уровня в глубину и два родителя в ширину, логический связующий объект и связующий объект Salesforce (Salesforce Junction Object), а также лимиты, которые кусаются.
- Владение и жизненный цикл. Кто владеет записью, таблица общего доступа, где владение превращается в доступ, и что происходит с записью на протяжении ее жизни.
- Как сохранять данные согласованными. Лестница согласованности: у каждого уровня есть цена, и вы никогда не «исправляете» историю, чтобы удовлетворить новое правило.
- Спроектируйте физическую модель Salesforce. Срез Steve Trucking от логической модели до Salesforce, выстроенный шаг за шагом, с рассуждениями.
Когда закончите, проверьте себя по учебному пособию главы: там чек-лист для экзамена, привычки за его пределами, ключевые термины и несколько вопросов.
Что здесь решает архитектор
Заголовок раздела «Что здесь решает архитектор »- Что Salesforce уже моделирует, прежде чем что-то изобретать: смотрите на корабль-носитель.
- Где живет каждый вид данных — в ядре, по ссылке или в архиве, — прежде чем выбирать структуру.
- Какая структура их хранит, зная, чем жертвует каждая.
- Как связаны объекты, кто владеет записями и что это значит для доступа и масштаба.
- От каких лицензий зависит модель — проверено до проектирования объектов, а не после.
- Как данные остаются согласованными и чего стоит каждый уровень согласованности.
За пределами экзамена: сборка с помощью ИИ может создать объекты и поля за минуты. Когда добавлять почти ничего не стоит, принцип «каждая структура — это обязательство» становится не менее, а более важным. Каждый модуль заканчивается тем, что ИИ меняет для этого решения.
Дополнительно
Заголовок раздела «Дополнительно »- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (на английском)
- Standard User Licenses (opens in a new tab), Salesforce Help (на английском)