Больше, чем база данных

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

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

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

Модуль 1 из 10 главы Архитектура данных Salesforce, глава 3 курса Data Architect. Каждый модуль самостоятелен. Далее: Смотрите на корабль-носитель: стандартные модели данных

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

Если вы уже какое-то время работаете администратором Salesforce, вы знаете, как создать объект. Setup, Object Manager, New Custom Object. Даете имя, добавляете несколько полей, собираете макет страницы — и через десять минут пользователи уже с ним работают.

Но что на самом деле произошло, когда вы нажали Save?

Если у вас опыт работы с базами данных, вы, скорее всего, представляете, что Salesforce пошел и создал новую таблицу. Нет. И понимание того, почему нет, — одно из мест, где вы начинаете переходить от мышления администратора или разработчика к мышлению архитектора.

Конечно, Salesforce хранит данные; под ним есть базы данных. Но Salesforce — это не база данных с красивым экраном сверху. Это платформа приложений, управляемая метаданными, и это различие определяет почти каждое решение в этом курсе.

У платформы есть форма

В главе 2 мы строили модель, вообще не думая о Salesforce. Это было намеренно: мы слушали существительные, строили концептуальную модель, добавляли атрибуты, ключи и связи и только потом спрашивали, как Salesforce должен это реализовать. Теперь нам нужно понять то, на чем мы это реализуем.

Для этого у меня есть простая фраза: у платформы есть форма. Salesforce дает нам объекты, поля, связи, безопасность, автоматизацию, API, транзакции, отчеты и поиск, и все это связано между собой. Когда я создаю объект, я не просто создаю место, куда класть строки. Я создаю то, что участвует в модели безопасности, с чем может работать автоматизация, что открывают API, что могут использовать отчеты, с чем могут связываться другие объекты и от чего будут зависеть пользователи, интеграции и, все чаще, агенты. Это намного больше, чем таблица.

Метаданные — это чертеж

Подумайте о здании. Есть само здание, и есть чертеж, который его описывает: где стены, где двери, как соединяются комнаты. Salesforce устроен так же. Определение объекта — это метаданные. Определение поля — метаданные. Связь — метаданные. Большая часть того, что мы настраиваем в Setup, — это метаданные, и платформа читает их во время выполнения, чтобы придать нашему org его структуру и поведение.

Salesforce описывает сердце платформы как мультитенантное и управляемое метаданными: когда мы определяем объект или поле, это определение хранится как метаданные, а не как новая физическая таблица или столбец для нашего org (Platform Multitenant Architecture (opens in a new tab)).

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

Это объясняет и то, на чем люди спотыкаются. Когда вы пишете SELECT Id, Name, Special__c FROM Account, это похоже на одну таблицу. А под капотом вы читаете стандартный объект и его пользовательское поле из разных структур, так что платформа выполняет соединение (join), которое вы никогда не писали. Индексы существуют, но работают не так, как индекс в традиционной базе данных. Для экзамена внутреннее устройство знать не нужно. Но нужно знать, что то, что вы видите в Object Manager, — это не точная картина физических таблиц один к одному, и что эта абстракция — одновременно сила платформы и причина, по которой она ведет себя именно так.

Click to enlarge

Смотрите на корабль-носитель

Одна из вещей, которые я говорю людям на занятиях: смотрите на корабль-носитель. Прежде чем изобретать какой-то сложный способ сделать что-то в Salesforce, посмотрите, как это делает сам Salesforce.

Возьмите организацию (Account). Ее создали не вы, а Salesforce. Но вы можете добавлять в нее поля, строить вокруг нее автоматизацию, менять ее макеты, открывать ее через API и связывать с ней другие объекты. Пользовательские объекты работают на том же механизме, поэтому стандартные и пользовательские объекты так похожи, когда мы на них строим. В Apex у них даже общий базовый класс — sObject.

Именно на этой привычке строится вся глава, и в следующем модуле мы присмотримся как следует: к стандартным моделям данных, которые Salesforce уже построил для вас.

Мы не строим рядом с Salesforce. Мы его расширяем.

API пришел вместе с объектом

Создайте таблицу в традиционной базе данных — и у вас есть таблица. Если с ней нужно работать другому приложению, кому-то предстоит еще поработать. Создайте объект в Salesforce — и платформа уже понимает его через свои прикладной и интеграционный слои: она использует те же метаданные, чтобы предоставлять REST и SOAP API, поэтому записи объекта можно создавать, читать, обновлять и удалять через них сразу, как только объект появился (Platform Multitenant Architecture (opens in a new tab)).

Я не проектировал API оттого, что создал объект. Платформа знает объект, его поля, их типы, его связи и его безопасность. Это одна из причин, почему разработка на Salesforce идет так быстро. И это же причина, почему создание объекта — решение крупнее, чем кажется: вы подключаете структуру к целой платформе приложений. И это работает в обе стороны. Люди, пришедшие из SQL Server или Oracle, иногда спрашивают меня, как загрузить данные прямо в базу. Никак. Все идет через API.

Многоквартирный дом

А теперь слово, которое вы слышите постоянно: мультитенантность. Я представляю ее как многоквартирный дом.

У вас есть своя квартира. Ваша мебель — ваша, и ваш ключ не должен открывать мою дверь. Но дом у нас общий: электричество, вода, лифты, вестибюль. Ваш org ощущается как ваша собственная среда, с вашими данными, вашими объектами, вашей автоматизацией. А под капотом Salesforce описывает каждый org как арендатора (tenant): данные, метаданные и логика каждого арендатора изолированы, а инфраструктура и сервисы общие (Platform Multitenant Architecture (opens in a new tab)). Так он может дать каждому клиенту настолько настраиваемую платформу, не запуская отдельный стек для каждого.

Но у общего дома есть последствия. Если один жилец покупает огромный кондиционер и одновременно включает фен и духовку, он выбивает пробки, и весь этаж погружается в темноту.

Лифт нельзя занять целиком

Задержитесь в этом доме еще на минуту. Представьте, что один жилец объявляет: «Мне нужен лифт с восьми до полудня. Больше никто им пользоваться не может». В общем доме так не получится, и в Salesforce тоже. Нельзя позволить одному арендатору без ограничений потреблять общие ресурсы и ухудшать работу платформы для всех остальных.

Вот откуда берутся governor limits (лимиты платформы). Если вы разрабатывали на Salesforce, вы, скорее всего, знакомились с ними как со списком чисел, который надо выучить. Я не хочу, чтобы вы думали о них так. Salesforce применяет лимиты на уровне транзакции и org, чтобы нагрузка одного арендатора не монополизировала общие вычислительные ресурсы (Architecture Basics (opens in a new tab)). Это и есть архитектура; каждый отдельный лимит — лишь ее реализация. Позже в курсе нам будут важны конкретные лимиты, потому что они меняют дизайн. А пока помните про дом: у вас огромная свобода перестраивать свою квартиру. Но занять лифт целиком вам не дадут.

ID в Salesforce — часть абстракции

У каждой записи Salesforce есть идентификатор, который понимает платформа, — ID записи, и он работает во всех возможностях платформы: в интерфейсе, в API, в отчетах, в автоматизации.

В главе 2 мы говорили, что хороший ключ уникален, неизменен, лишен смысла и никогда не содержит персональных данных (PII). ID Salesforce отвечает этому внутри Salesforce. Но это не то же самое, что бизнес-ключ. В вашей компании все равно может быть номер клиента в ERP, табельный номер сотрудника или номер заказа партнера, который что-то значит во всех системах. Не путайте «Salesforce знает, какая это запись» с «предприятие знает, какая это бизнес-сущность». Это разные задачи идентификации, и ко второй мы вернемся в интеграции и мастер-данных.

Объекты — это больше, чем хранилище

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

Выбранный объект определяет, какие возможности приходят вместе с ним. Тип поля влияет на проверку, интеграцию, поиск, отчетность и на то, как другие системы читают данные. Связь определяет жизненный цикл, владение, общий доступ и удаление. То, где мы размещаем данные, влияет на хранение, производительность и масштаб. И поскольку все это работает на общей платформе, выбор, безобидный при сотне записей, может вести себя совсем иначе при сотне миллионов. Мы разберем эти решения по одному.

За пределами экзамена: что меняет ИИ. Годами хорошие имена и описания помогали следующему администратору или разработчику понять, что мы построили. Теперь этот контекст читают и машины. У ИИ-системы, работающей с полем Flag2__c, та же проблема, что и у нового разработчика: что эта штука означает? Метаданные больше не украшение; это часть того, как машины понимают приложение.

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

• Проектирую ли я для той платформы, на которой на самом деле работаю, или отношусь к Salesforce как к обычной базе данных?
• Какие части моего дизайна — бизнес-понятия, а какие — решения по реализации в Salesforce?
• Какое поведение платформы приходит вместе со структурой, которую я собираюсь создать?
• Какие лимиты — выражение общей архитектуры, и какие из них повлияют на этот дизайн?
• Если эту структуру будет трудно изменить потом, отношусь ли я к ней как к архитектурному решению?

В главе 2 мы говорили: не проектируйте из Setup. Теперь вы знаете еще одну причину. Нажатие New Custom Object не просто дает вам таблицу; оно подключает еще один кусок вашей архитектуры к мультитенантной платформе, управляемой метаданными. Но прежде чем решать, какой объект создавать, есть вопрос попроще: должны ли эти данные вообще жить здесь? Об этом дальше.

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

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab), на английском, проверено 2026-10-02, перепроверено 2026-10-12: определения объектов и полей хранятся как метаданные, а не как новые таблицы; общие таблицы (MT_Objects, MT_Fields, MT_Data, MT_Indexes) привязаны к OrgID; те же метаданные предоставляют REST и SOAP API.
• Salesforce Architects, Architecture Basics (opens in a new tab), на английском, проверено 2026-10-02, перепроверено 2026-10-12: governor limits и лимиты выполнения, чтобы код и транзакции «не монополизировали общие вычислительные ресурсы».