Де живуть ці дані?
Також доступно 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 і створюєте користувацький об’єкт. Я розумію. За десять хвилин у вас є вкладка, макет сторінки і подання списку. І ось що я кажу кожній групі: щойно ви створили цей новий об’єкт, ви вже мислите як архітектор, хотіли того чи ні. Бо кожен створений об’єкт — це зобов’язання. Він займає сховище. Він обростає лімітами. Він отримує модель спільного доступу, проєктували ви її чи ні. Він потребує ліцензії для кожного, хто його торкається. А щойно від нього залежать люди й інтеграції — успіхів вам його прибрати.
Тож перше архітектурне рішення — не який об’єкт. Воно — де мають жити ці дані? Зробіть це правильно, і тип об’єкта майже обере себе сам.
В ядрі і поза ядром
Section titled “В ядрі і поза ядром ”Спершу слово, яке я вживатиму часто: ядро (core). Ядро — це платформа Salesforce, на якій працює ваша org: метаданими керована мультитенантна платформа з модуля 1, де живуть об’єкти продажів і обслуговування з модуля 2 і кожен користувацький об’єкт, який ви будуєте в модулі 3. Коли я кажу, що дані в ядрі (on core), я маю на увазі, що вони зберігаються у вашій org, в її об’єктах.
Не всі дані живуть там. Data 360 тримає свої дані у власному сховищі, поза об’єктами вашої org (це поряд з ядром (near-core): керується в ядрі, а його дані розміщуються поза ядром; докладніше в розділі 4). А ще є все, що працює у вашій компанії і взагалі не є Salesforce: ERP, склад, система замовлень, платформа партнера. Усе це — поза ядром (off core). Salesforce може до цього дотягнутися, показати і використати, але ваша org цього не зберігає.
В ядрі є два види об’єктів, які справді містять ваші записи: sObjects, стандартні й користувацькі (__c), і big objects (__b). Поза ядром ви дістаєтеся до даних через зовнішні об’єкти (__x) та інші інструменти інтеграції. Пам’ятайте ці суфікси з модуля 3: вони кажуть вам, де живуть дані, лише за назвою.
Я думаю про це як про офіс. Деякі речі мають лежати на вашому столі, де ви користуєтеся ними щодня. Деякі речі вам треба лише подивитися в чужій шафі з документами. А деякі йдуть у коробках у сарай на подвір’ї. Це дає мені три відповіді.
1. В ядрі: вони лежать на вашому столі
Section titled “1. В ядрі: вони лежать на вашому столі ”Дані щодня створюються, змінюються й використовуються в Salesforce: акаунти, звернення, можливості, робочі замовлення. Тримати їх у sObjects — це як тримати їх на передньому плані офісу. Саме для цього існують стандартні й користувацькі об’єкти, і ви отримуєте все: макети сторінок, спільний доступ, автоматизацію, звітність, пошук, а тепер і функції ШІ, побудовані на моделі даних.
Утім, ваш стіл не безкоштовний. Дані в ядрі коштують сховища, порахованого так, як рахує Salesforce, — запис за записом, а не колонка за колонкою, — а документи окремо рахуються у сховищі файлів. Ми розглянули обидва в модулі 2. Великим обсягам фото і сканів часто місце поза ядром, а Salesforce зберігає лише посилання.
2. За посиланням: вони лежать у чужій шафі з документами
Section titled “2. За посиланням: вони лежать у чужій шафі з документами ”Дані належать іншій системі (ERP, сховищу даних, платформі замовлень), і ця система лишається джерелом правди. Користувачам треба бачити їх у Salesforce, можливо, пов’язати із записом, але Salesforce не потрібна власна копія. Ви також почуєте, як це називають віртуальними даними: вони з’являються в Salesforce віртуально, ніколи там не зберігаючись.
Це зовнішні об’єкти через Salesforce Connect. Я люблю казати: воно виглядає як качка і ходить як качка, але це не качка. Воно з’являється як sObject: його можна поставити на макет сторінки й у пов’язані списки і пов’язати з вашими записами через зовнішні й непрямі lookup. Але дані не зберігаються в ядрі. Щоразу, коли ви його торкаєтеся, він робить callout. Відкрийте запис, завантажте пов’язаний список, запустіть звіт — і Salesforce іде й питає іншу систему. Це означає затримку, і ваша сторінка доступна рівно настільки, наскільки доступна система за нею.
Люди сперечаються через вартість ліцензії, тож порахуйте так, як я рахую на заняттях. Connect ліцензується за кінцевою точкою, і одна кінцева точка може приносити багато об’єктів. А тепер запитайте, скільки коштує збудувати й підтримувати альтернативу: користувацький компонент, код callout за ним і розробника на чергуванні, коли щось ламається. Часто ліцензія дешевша, а ваші адміністратори можуть налаштувати це без жодного рядка коду. Де це не працює: дані, які ваші користувачі редагують увесь день або на яких активно будують звіти.
Посилатися можна й на документи. Якщо контракт уже живе в SharePoint Online, OneDrive, Google Drive чи Box, Files Connect дає користувачам дістатися до нього із Salesforce, не копіюючи його всередину.
Salesforce Connect — не єдиний спосіб посилатися на дані. Іноді це власна логіка: код, що в реальному часі викликає іншу систему і показує її дані на сторінці, не зберігаючи копії. Це дає повний контроль — і повну відповідальність за callout, помилки й підтримку. А ще Data 360 теж може федерувати без копіювання. Цьому вибору присвячено окремий розділ (Віртуалізація, федерація і zero-copy). Тут суть — саме рішення: посилайтеся, а не копіюйте.
3. В архіві: вони йдуть у сарай на подвір’ї
Section titled “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, а екран пошуку показував поточні записи з архівними одразу під ними. Роки потому все досі працює добре.
Застосування: Steve Trucking
Section titled “Застосування: Steve Trucking ”Steve Trucking — наш наскрізний сценарій: сімейна компанія доставки «останньої милі», що забирає побутову техніку й електроніку з розподільчих центрів великих мереж, а потім доставляє і встановлює її в домівках клієнтів. Чотири види її даних, три відповіді:
| Дані | Де вони живуть | Чому |
|---|---|---|
| Сьогоднішні доставки, бригади й візити | В ядрі | Диспетчери й бригади працюють у них увесь день |
| Деталі замовлення роздрібної мережі | За посиланням (або тонка копія в ядрі) | Система мережі — джерело правди |
| Історія доставок трирічної давнини | В архіві | Зберігається для претензій і трендів; майже ніхто не відкриває |
| Фото доставок | Поза ядром, з посиланням | Тисячі на день; зберігаються поза Salesforce з посиланням на доставці |
Ось те саме у вигляді моделі даних. Доставка живе в ядрі, де люди працюють із нею цілий день. Через три роки вона переїжджає в Історію доставок, big object: усе ще в ядрі, але вже в сараї. Замовлення партнера з’являється як зовнішній об’єкт, __x: Salesforce пов’язує з ним доставку, але дані лишаються в системі роздрібної мережі. А фото живуть повністю поза ядром, з посиланням від доставки. Одна модель, три домівки.
Кожна справжня org має всі три. У біду потрапляють ті, хто клав усе в ядро, бо створити об’єкт було кнопкою за замовчуванням.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”- Дім для кожного виду даних, до проєктування будь-якого об’єкта: в ядрі, за посиланням чи в архіві.
- Джерело правди. Якщо даними володіє інша система, Salesforce не повинен тихо ставати другим майстром.
- Шлях доступу до всього, що поза ядром. Даним за посиланням потрібні доступне джерело і прийнятна затримка; архівним даним — спосіб, яким люди їх знаходитимуть.
- Зростання сховища. Порахуйте зараз (записи на день, помножені на зростання, помножені на строк зберігання), а не тоді, коли прийде попередження про сховище.
За межами іспиту: ШІ підвищує ставки «в ядрі». Функції ШІ й агенти найкраще працюють із даними, які розуміє платформа: даними в стандартних і користувацьких об’єктах, добре названими й добре описаними. Це тягне до того, щоб класти в ядро більше. Опирайтеся цьому для не тих даних. Агент, заземлений на застарілій копії даних ERP, дає впевнені хибні відповіді. Часто краще посилатися на живе джерело або тримати в ядрі невеликий, добре описаний зріз. Те, де ШІ читає дані, тепер частина рішення про те, де дані живуть.
Додаткові матеріали
Section titled “Додаткові матеріали ”- 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 і Проєктування для масштабу