Где живут эти данные?

🌐 Также доступно на 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)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 4 из 10 главы Архитектура данных Salesforce, глава 3 курса Data Architect. Каждый модуль самостоятелен. Назад: Постройте свое: пользовательские объекты · Далее: Выберите правильный объект

Вопрос, на который отвечает этот модуль: прежде чем создавать объект — где на самом деле должны жить эти данные: в ядре, в Salesforce, по ссылке там, где они уже лежат, или в архиве?

Позвольте задать вам вопрос. Вам на стол ложится новое требование. Что вы делаете первым делом?

Если вы похожи на большинство из нас, вы открываете Setup и создаете пользовательский объект. Понимаю. За десять минут у вас есть вкладка, макет страницы и представление списка. И вот что я говорю каждой группе: в тот момент, когда вы создаете этот новый объект, вы уже думаете как архитектор, хотели вы того или нет. Потому что каждый созданный объект — это обязательство. Он занимает хранилище. Он подпадает под лимиты. Он получает модель общего доступа, проектировали вы ее или нет. Каждому, кто к нему прикасается, нужна лицензия. И как только от него начнут зависеть люди и интеграции — удачи вам его убрать.

Поэтому первое архитектурное решение — не какой объект. А где должны жить эти данные? Решите это правильно, и тип объекта почти выберется сам.

В ядре и вне ядра

Сначала слово, которое я буду часто использовать: ядро (core). Ядро — это платформа Salesforce, на которой работает ваш org: мультитенантная платформа, управляемая метаданными, из модуля 1, где живут объекты продаж и обслуживания из модуля 2 и каждый пользовательский объект, который вы строите в модуле 3. Когда я говорю, что данные в ядре (on core), я имею в виду, что они хранятся в вашем org, в его объектах.

Не все данные живут там. Data 360 хранит свои данные в собственном хранилище, за пределами объектов вашего org (это near-core, рядом с ядром: управляется в ядре, а данные размещены вне ядра; подробнее в главе 4). А еще есть все, что работает в вашей компании и вообще не является Salesforce: ERP, склад, система заказов, платформа партнера. Все это — вне ядра (off core). Salesforce может до этого дотянуться, показать это и использовать, но ваш org это не хранит.

В ядре есть два вида объектов, которые действительно хранят ваши записи: sObject — стандартные и пользовательские (__c) — и big objects (__b). Вне ядра вы обращаетесь к данным через внешние объекты (__x) и другие инструменты интеграции. Помните эти суффиксы из модуля 3: они говорят, где живет кусок данных, по одному только имени.

Я думаю об этом как об офисе. Что-то должно лежать у вас на столе, потому что вы пользуетесь этим каждый день. Что-то нужно просто посмотреть в чужом картотечном шкафу. А что-то отправляется в коробках в сарай на заднем дворе. Это дает мне три ответа.

1. В ядре: это лежит у вас на столе

Данные создаются, меняются и используются в Salesforce каждый день: организации, обращения, возможности, рабочие заказы. Хранить их в sObject — все равно что держать их на виду в своем офисе. Для этого и существуют стандартные и пользовательские объекты, и вы получаете все: макеты страниц, общий доступ, автоматизацию, отчетность, поиск и теперь функции ИИ, построенные на модели данных.

Но ваш стол не бесплатный. Данные в ядре стоят хранилища, и считается оно так, как считает Salesforce, — запись за записью, а не столбец за столбцом, а документы отдельно расходуют файловое хранилище. Мы разобрали и то и другое в модуле 2. Большим объемам фотографий и сканов часто место вне ядра, а в Salesforce остается только ссылка.

2. По ссылке: это лежит в чужом картотечном шкафу

Данные принадлежат другой системе (ERP, хранилищу данных, платформе заказов), и эта система остается источником истины. Пользователям нужно видеть их в Salesforce, может быть, связать с записью, но Salesforce не нужна собственная копия. Это еще называют виртуальными данными: они появляются в Salesforce виртуально, никогда там не храня́сь.

Это внешние объекты через Salesforce Connect. Я люблю говорить: выглядит как утка, ходит как утка, но это не утка. Он показывается как sObject: его можно поставить на макеты страниц и в связанные списки и связать с вашими записями через external lookup и indirect lookup. Но данные не хранятся в ядре. Каждый раз, когда вы к нему прикасаетесь, он делает вызов (callout). Открыли запись, загрузили связанный список, запустили отчет — и Salesforce идет и спрашивает другую систему. Это значит задержка, и ваша страница доступна ровно настолько, насколько доступна система за ней.

Люди возражают из-за стоимости лицензии, поэтому посчитайте так, как я считаю на занятиях. Connect лицензируется по конечным точкам (endpoint), и одна конечная точка может принести много объектов. А теперь спросите, сколько стоит построить и поддерживать альтернативу: пользовательский компонент, код вызовов за ним и разработчика на дежурстве, когда это сломается. Часто лицензия дешевле, и ваши администраторы могут настроить все без единой строки кода. Где это не работает: данные, которые пользователи редактируют весь день или по которым активно строят отчеты.

На документы тоже можно ссылаться. Если договор уже лежит в SharePoint Online, OneDrive, Google Drive или Box, Files Connect позволяет пользователям открыть его из Salesforce, не копируя внутрь.

Salesforce Connect — не единственный способ сослаться на данные. Иногда это пользовательская логика: код, который в реальном времени вызывает другую систему и выводит ее данные на страницу, не сохраняя копию. Это дает полный контроль — и полную ответственность за вызов, ошибки и поддержку. А Data 360 тоже умеет федерировать без копирования. Этому выбору посвящена отдельная глава (Виртуализация, федерация и Zero-Copy). Здесь важно само решение: ссылайтесь, а не копируйте.

3. В архиве: это отправляется в сарай на заднем дворе

История, журналы аудита, старые транзакции. Хранить их нужно, иногда годами, но почти никто их не открывает. И именно это команды откладывают. Когда группа говорит мне, что у них есть объект с 50 млн записей, и спрашивает, зачем им архивировать, я спрашиваю в ответ: если вы не архивируете сегодня, вы вообще когда-нибудь начнете? При 50 млн сегодня вы движетесь к 100, 150, 200 млн.

Сараев два. Один — в ядре: big objects. Представьте, что вы храните данные в гараже. Можно хранить огромное число записей, но их нельзя поставить на макет страницы, нет стандартного интерфейса и отчетности, а запросы идут через индекс big object — по точному совпадению или диапазону (Big Objects Best Practices (opens in a new tab)). Безопасность — только разрешения на объект и поля, без общего доступа к записям, и автоматизация на них не работает. Я использовал Salesforce Connect десятки раз, а big objects — всего раз или два. Они работают, но неуклюжи, и я написал свою долю обходных путей, чтобы добраться до данных. Поэтому мой совет: сделайте прототип, прежде чем предлагать, и спланируйте, как люди будут находить данные, прежде чем их выбирать.

Другой сарай — вне ядра: хранилище данных или база где-то еще (Проектирование для масштаба). Часто это сарай получше, и он не обязательно с глаз долой. Архивные данные вне ядра все равно могут появляться в отчетах через инструменты вроде Tableau и оставаться доступными из Salesforce — через Salesforce Connect или другой способ виртуализации, — когда кому-то нужно заглянуть в прошлое.

Расскажу о проекте, где мы сделали это правильно с самого начала. У клиента из розничной торговли было больше 1 200 точек. Мне сказали: «У нас всего сто записей на прием в день на магазин. Ерунда». Потом я посчитал: сто в день, шесть дней в неделю (около 305 дней в году), на 1 200 точках — это больше 36 млн записей на прием в год. Потом они упомянули, что каждый визит создавал две записи: одну на стойке приема и одну для мастерской: больше 73 млн записей в год. Потом они захотели пять лет истории: больше 360 млн записей, еще до всякого роста. Мы еще не запустились, а я уже видел, как поезд мчится прямиком на станцию «большие объемы данных». Поэтому архив построили раньше, чем мы собрали хотя бы одну запись: старые записи на прием уходили в big objects, а экран поиска показывал текущие записи, и архивные — прямо под ними. Годы спустя это до сих пор прекрасно работает.

Click to enlarge

Применяем на практике: Steve Trucking

Steve Trucking — наш сквозной сценарий: семейная компания доставки «последней мили», которая забирает бытовую технику и электронику в распределительных центрах крупных розничных сетей, а потом доставляет и устанавливает ее у клиентов дома. Четыре вида ее данных, три ответа:

Данные	Где они живут	Почему
Сегодняшние доставки, бригады и записи на прием	В ядре	Диспетчеры и бригады работают с ними весь день
Детали заказа розничной сети	По ссылке (или тонкая копия в ядре)	Источник истины — система розничной сети
История доставок трехлетней давности	В архиве	Хранится для претензий и трендов; почти никто ее не открывает
Фотографии доставок	Вне ядра, по ссылке	Тысячи в день; хранятся вне Salesforce со ссылкой на доставке

Вот то же самое в виде модели данных. Доставка (Delivery) находится в ядре, где люди работают с ней весь день. Через три года она переходит в Delivery History, big object: все еще в ядре, но уже в сарае. Заказ партнера появляется как внешний объект, __x: Salesforce связывает с ним доставку, но данные остаются в системе розничной сети. А фотографии живут полностью вне ядра, со ссылкой из доставки. Одна модель, три дома.

Click to enlarge

В каждом реальном org есть все три. В беду попадают те, кто кладет все в ядро, потому что создание объекта было кнопкой по умолчанию.

Что здесь решает архитектор

• Дом для каждого вида данных — до того как проектировать любой объект: в ядре, по ссылке или в архиве.
• Источник истины. Если данными владеет другая система, Salesforce не должен потихоньку становиться вторым мастером.
• Путь доступа ко всему, что вне ядра. Данным по ссылке нужен доступный источник и приемлемая задержка; архивным данным нужен способ, которым люди будут их находить.
• Рост хранилища. Посчитайте сейчас (записей в день, умножить на рост, умножить на срок хранения), а не когда придет предупреждение о хранилище.

За пределами экзамена: ИИ повышает ставки для «в ядре». Функции ИИ и агенты лучше всего работают с данными, которые понимает платформа: данными в стандартных и пользовательских объектах, с хорошими именами и описаниями. Это тянет класть в ядро больше. Не поддавайтесь, когда речь о неподходящих данных. Агент, заземленный на устаревшую копию данных ERP, дает уверенные и неверные ответы. Часто лучше сослаться на живой источник или держать в ядре небольшой, хорошо описанный срез. То, где ИИ читает данные, теперь часть решения о том, где данные живут.

Дополнительно

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (на английском, проверено 2026-09-25)
• Files Connect FAQ (opens in a new tab), Salesforce Help (на английском, проверено 2026-09-25)
• В этом курсе: Виртуализация, федерация и Zero-Copy и Проектирование для масштаба