Кожна структура — це зобов’язання
Також доступно 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 на рішення.
Зображення згенеровано ШІ.
Структури з першого погляду
Section titled “Структури з першого погляду ”Salesforce дає вам шість місць для зберігання даних. Я кладу їх на один слайд, бо перша робота — знати, що всі вони існують:
| Структура | Для чого вона | Підступ |
|---|---|---|
| Стандартні об’єкти | Власна модель Salesforce: Account, Contact, Opportunity, Case, Asset та інші | Використовуйте їх за призначенням, інакше вони з вами боротимуться |
| Користувацькі об’єкти | Ваші власні бізнес-дані | Легко створити, важко вивести з ужитку |
| Зовнішні об’єкти | Дані, що живуть в іншій системі й показуються в Salesforce | Кожен дотик — це callout |
| Big objects | Величезні обсяги, які треба зберігати, але рідко відкривати | Немає стандартного інтерфейсу чи звітності; запити — через індекс |
| Files | Документи, фото та інший контент | Файлове сховище швидко зростає |
| Attachments | Старий спосіб зберігати файли | Застаріле: використовуйте Files |
Обрати структуру — лише частина справи. Перед структурою стоїть запитання, де дані взагалі мають жити: в ядрі (on core), за посиланням там, де вони вже є, чи в архіві.
Шлях через цей розділ
Section titled “Шлях через цей розділ ”Розділ великий, тож він складається з десяти частин. Кожна самостійна. У розділі 2 ми вирішили, якою має бути модель; тут ми вирішуємо, як вона має жити в Salesforce.
- Платформа даних Salesforce: більше ніж база даних. Чим Salesforce відрізняється і чому платформа має форму.
- Дивіться на материнський корабель: стандартні моделі даних. Моделі продажів і обслуговування, які Salesforce уже збудував, файли, сховище і персональні акаунти.
- Побудуйте своє: користувацькі об’єкти. Що вирішує екран New Custom Object, поля, яких ви не створювали, і як прочитати будь-яке ім’я API: стандартне, користувацьке чи з керованого пакета.
- Де живуть ці дані? В ядрі, за посиланням чи в архіві — вирішується до створення будь-якого об’єкта.
- Оберіть правильний об’єкт. Тест чистої відповідності, багаж, який приносять стандартні об’єкти, персональні акаунти і ліцензії, що визначають, чим люди можуть користуватися.
- Поля — це теж архітектура. Тип поля за типом поля, поведінка, що дивує людей, і чому кожне поле отримує опис.
- Зв’язки мають наслідки. Lookup чи master-detail, три рівні вглиб і два батьки вшир, логічний об’єкт-з’єднувач і об’єкт-з’єднувач Salesforce (Salesforce Junction Object), і ліміти, що кусаються.
- Власність і життєвий цикл. Хто володіє записом, таблиця спільного доступу, де власність стає доступом, і що відбувається із записом протягом його життя.
- Як зберігати дані узгодженими. Драбина узгодженості: кожен рівень має свою ціну, і ви ніколи не «виправляєте» історію заради нового правила.
- Спроєктуйте фізичну модель Salesforce. Фрагмент Steve Trucking — від логічної моделі до Salesforce, побудований крок за кроком, з обґрунтуванням.
Коли закінчите, перевірте себе за навчальним посібником до розділу: контрольний список для іспиту, звички, що виходять за його межі, ключові терміни і кілька запитань.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”- Що Salesforce уже моделює, перш ніж щось вигадувати: дивіться на материнський корабель.
- Де живе кожен вид даних — в ядрі, за посиланням чи в архіві, — перш ніж обирати структуру.
- Яка структура їх містить, знаючи, чим кожна жертвує.
- Як пов’язані об’єкти, хто володіє записами і що це означає для доступу й масштабу.
- Від яких ліцензій залежить модель, перевірено до проєктування об’єктів, а не після.
- Як дані лишаються узгодженими і чого коштує кожен шар узгодженості.
За межами іспиту: будування з допомогою ШІ може створювати об’єкти й поля за хвилини. Коли додавати майже безкоштовно, «кожна структура — це зобов’язання» стає важливішим, а не менш важливим. Кожен модуль завершується тим, що ШІ змінює для цього рішення.
Додаткові матеріали
Section titled “Додаткові матеріали ”- 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 (англійською)