Більше ніж база даних

🌐 Також доступно 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 ми сказали, що добрий ключ — унікальний, незмінний, без змісту і ніколи не персональні дані. 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 і ліміти виконання, щоб код і транзакції «не монополізували спільні обчислювальні ресурси».