Перейти до вмісту
SteveTechArcSteveTechArc Courses

Перекіс власності, батьківських записів і lookup

Також доступно 19 мовами

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Español (México) · Français (Canada) · Deutsch (Schweiz)

A wall of identical mailboxes, all neat and closed except one, forced open and stuffed, with letters and parcels piled on the floor beneath it.
Зображення згенеровано ШІ

Модуль 2 з 4 розділу Проєктування для масштабу, розділ 7 курсу Data Architect. Кожен модуль самостійний. Попередній: Коли обсяг змінює все · Наступний: Обсяг зустрічає модель спільного доступу

Питання, на яке відповідає цей модуль: Що відбувається, коли забагато записів вказують на одне?

Проблеми великих обсягів даних не завжди пов’язані з тим, що записів забагато. Іноді річ у тім, що забагато записів пов’язані з одним і тим самим: одним власником, одним акаунтом, одним батьківським записом, одним значенням lookup. Подумайте про дорожній рух. Місто може мати мільйони автомобілів і все одно функціонувати. Проблеми починаються, коли всі о п’ятій вечора з’їжджають з автостради на тому самому виїзді. Загальна кількість важить, і концентрація теж. Я називаю ці концентрації гарячими точками; Salesforce називає їх перекосом даних (data skew). Є кілька видів, і під усіма ними одна ідея: забагато активності, що сходиться в одній точці моделі.

Перекіс «батько–нащадок»

Section titled “Перекіс «батько–нащадок» ”

The easiest to picture. One account with 100 contacts: nothing unusual. A thousand: probably fine. Ten thousand: now I’m paying attention. My design rule is no more than about 10,000 children under one parent, and Salesforce’s guidance draws the same line: “a large number of child records (10,000 or more) with a single parent account” is a common cause of poor performance (Parent-Child Data Skew (відкривається в новій вкладці)). Salesforce’s own example shows why. Put 300,000 contacts under one account. A user who can see one of those contacts gets implicit access to the account. When that user loses access to the contact, Salesforce has to check the other 299,999 contacts before it can decide whether to remove the user’s access to the account. Do that for many users at once, and it gets expensive. Salesforce also names one way to take part of that cost away: where your security requirements allow, set the child object to Controlled by Parent, so there are no parent implicit shares to maintain (same source). In practice, it’s the most common skew I see, and I’ve seen users notice visible lag at around 20,000 children under one parent. Where somebody feels it depends on what the system is doing. That’s why 10,000 is a design threshold, not a promise that record 10,001 breaks anything. The real question is: why are all these records pointing at the same parent? ⟲

Same contacts, different concentration Three hundred dots, each standing for 1,000 contacts. Step 1: every dot has a line to one account, Unassigned Contacts, drawn in amber with a glow: 300,000 contacts on one account, 30 times the 10,000 threshold. Step 2: the same dots in the same places, now green, with their lines spread evenly across 30 small accounts, Unassigned 001 to Unassigned 030: 30 accounts, no more than 10,000 each. each dot = 1,000 contacts Unassigned Contacts 300,000 contacts → 1 account 30 × the 10,000 threshold © 2026 Twinshark LLC · stevetecharc.com
Натисніть, щоб збільшити

Step 1 of 2: every line points at one account. That’s the hot spot. ⟲

Акаунт «Unassigned» і пули акаунтів

Section titled “Акаунт «Unassigned» і пули акаунтів ”

The classic case is contacts with no real account. Somebody decides every contact needs an account, so they create Unassigned Contacts and put every contact without an account there. Problem solved, until there are 300,000 contacts under it. We created an artificial hot spot because the model required us to put everything somewhere, and the relationship doesn’t even carry business meaning. It worked beautifully at 500 records. Then the Number of Zeros caught up with it. ⟲

What do you do when you’ve got a million contacts under it? I’ve seen child accounts by state, one unhandled-contacts account per state. I’ve seen an automatic version: whenever an account reaches 10,000, create another one. It can be a little awkward, but it spreads the load. ⟲

One answer is an account pool: Unassigned Contacts 001, 002, 003 and so on, with the children spread across them, each kept under the threshold. It works, and it’s Salesforce’s own advice: “Distribute child records so that no parent has more than 10,000 child records,” and for contacts without real accounts, “set up several dummy accounts and distribute the contacts among them” (Best Practices for Deployments with Large Data Volumes: General (відкривається в новій вкладці), Winter ‘27). But those aren’t real accounts; they’re architecture artifacts. Users will ask who “Unassigned Contacts 017” is and why it’s in their search results. So when I use a pool, I hide the placeholder parents from normal business experiences as much as I can. It’s a recurring trade-off: sometimes scale forces a structure that exists for the platform, not the business. When it does, don’t pretend it’s business data. Name it, document it, hide it where appropriate. ⟲

Same contacts, different concentration Three hundred dots, each standing for 1,000 contacts. Step 1: every dot has a line to one account, Unassigned Contacts, drawn in amber with a glow: 300,000 contacts on one account, 30 times the 10,000 threshold. Step 2: the same dots in the same places, now green, with their lines spread evenly across 30 small accounts, Unassigned 001 to Unassigned 030: 30 accounts, no more than 10,000 each. each dot = 1,000 contacts Unassigned 001 Unassigned 030 30 accounts no more than 10,000 each © 2026 Twinshark LLC · stevetecharc.com
Натисніть, щоб збільшити

Step 2 of 2: the same contacts, spread across a pool. Nothing moved but where they point. ⟲

Master-Detail at Volume

Section titled “Master-Detail at Volume”

Contacts under an account are a lookup. Master-detail is a different decision, and it’s one you make in the data model, long before the records arrive. Here’s the question I ask in class: would an invoice ever have more than 10,000 line items? No, it never would. So an invoice and its lines can be master-detail all day long. Now ask the same question of every master-detail relationship you’re about to build: at the volume we expect, will one parent ever pass 10,000 children? ⟲

Salesforce draws the same line: “As a best practice, don’t exceed 10,000 child records for a master-detail relationship” (Considerations for Object Relationships (відкривається в новій вкладці)). Master-detail is the strongest relationship Salesforce gives you, and that’s exactly why the number matters. The detail record has no owner of its own; its access is controlled by the parent. Delete the parent, and every child goes with it. A child can’t move to another parent unless you allowed reparenting. Roll-up summaries on the parent have to keep up as the children change. And saving a child can lock the parent, which is why Salesforce’s loading advice is to group child records by their parent “to minimize locking conflicts” (Loading Data from the API (відкривається в новій вкладці)). With ten children, none of that is noticeable. With a hundred thousand, every one of them is. ⟲

It’s also hard to undo. A master-detail relationship can only be converted to a lookup when the parent has no roll-up summary fields, and converting it changes the child’s sharing to Public Read/Write (same source). By the time volume tells you it was the wrong choice, the relationship may be holding up reports, sharing and automation. Count the children before you choose the relationship. ⟲

Steve Trucking has one of these decisions in its model. Each Retail Partner sends a Manifest (Manifest__c, a custom object) for each distribution center, for each working day. Manifest is custom, so master-detail to the partner’s account is allowed, and it’s tempting: the manifest would inherit the partner’s sharing, which is exactly the isolation we want. Now count. Our largest partner has nine or more DCs: nine manifests a working day, about 2,700 a year. Past 10,000 in under four years, under one parent, and every manifest revised on the day, so every revision would touch the partner’s account. That’s why the model makes Manifest a lookup and handles partner access through sharing. The invoice stays small; the manifests keep coming. ⟲

Master-detail where the parent stays small Two relationships side by side. On the left, in green, master-detail where the parent stays small: an Invoice (Invoice__c) has Invoice Lines (Invoice_Line__c) on a thick master-detail line, a few lines each. On the right, in amber, a lookup where the children keep coming: a Retail Partner (Account, the largest with nine or more distribution centers) sends Manifests (Manifest__c, one per distribution center a day) on a thin lookup line, about 2,700 a year. Underneath: Salesforce's best practice is no more than 10,000 children for one master-detail parent, and the largest partner passes that in under four years. MASTER-DETAIL: THE PARENT STAYS SMALL LOOKUP: THE CHILDREN KEEP COMING has a few lines each Invoice Invoice__c · stays small Invoice Line Invoice_Line__c Salesforce's best practice: no more than 10,000 children for one master-detail parent. The largest partner passes that in under four years. exactly one zero or one one or many zero or many master-detail lookup © 2026 Twinshark LLC · stevetecharc.com
Натисніть, щоб збільшити

Step 1 of 2: master-detail, where the parent stays small. ⟲

Master-detail where the parent stays small Two relationships side by side. On the left, in green, master-detail where the parent stays small: an Invoice (Invoice__c) has Invoice Lines (Invoice_Line__c) on a thick master-detail line, a few lines each. On the right, in amber, a lookup where the children keep coming: a Retail Partner (Account, the largest with nine or more distribution centers) sends Manifests (Manifest__c, one per distribution center a day) on a thin lookup line, about 2,700 a year. Underneath: Salesforce's best practice is no more than 10,000 children for one master-detail parent, and the largest partner passes that in under four years. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.34.0", "built": "2026-10-20", "id": "DGM-DA-LDV-24", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "object-model/physical 1.8.0", "theme": "stevetecharc 1.4.0"} MASTER-DETAIL: THE PARENT STAYS SMALL LOOKUP: THE CHILDREN KEEP COMING has a few lines each sends 2,700 a year Invoice Invoice__c · stays small Invoice Line Invoice_Line__c Retail Partner Account · largest has 9+ DCs Manifest Manifest__c · one per DC a day Salesforce's best practice: no more than 10,000 children for one master-detail parent. The largest partner passes that in under four years. exactly one zero or one one or many zero or many master-detail lookup © 2026 Twinshark LLC · stevetecharc.com
Натисніть, щоб збільшити

Step 2 of 2: a lookup, where the children keep coming. ⟲

Watch Account with its contacts and opportunities too. It isn’t master-detail, but it behaves like a pseudo master-detail, with implicit sharing to the parent, which is why the 10,000 guidance shows up there as well. None of this means never use master-detail at scale. It means don’t choose a strongly coupled relationship and then act surprised that the records are strongly coupled. ⟲

Test knowledge. Know the 10,000-children guidance for master-detail, and what master-detail brings with it at volume: no owner on the detail (access controlled by the parent), cascade delete, no reparenting unless allowed, roll-up summaries, and parent locking when children are saved. Converting to a lookup needs no roll-up summaries on the master. ⟲

Перекіс власності

Section titled “Перекіс власності ”

Now the owner. I ask the room: who owns a million records? The admin? Is the admin sitting there creating a million records? Usually it’s the integration user or the data load user. The records come in, and nobody knows who to give them to. We create an integration user, it creates records, nobody thinks about ownership (“it’s just the integration user”), and a year later that user owns 2 million records. Salesforce calls it ownership data skew when one user owns more than 10,000 records of an object, and the classic example is all the unassigned leads parked on a dummy user (Ownership Data Skew (відкривається в новій вкладці)). That doesn’t mean a user can never own more. It means understanding the consequences: ownership isn’t a Created By stamp. It drives the role hierarchy, sharing rules and recalculation: behind the scenes, Salesforce keeps share records for the owner’s records above them in the role hierarchy. Attach millions of records to one owner who sits deep in the sharing model, and changing anything about that owner gets expensive. ⟲

The guidance matches what I teach in class. If a few users must own a very large number of records, give them no role; if they need one, put them in a separate role at the top of the hierarchy and don’t move them, and keep them out of public groups used as sources for sharing rules (same source). One catch with the top role: that user inherits access to all the data owned by or shared with the users below them. You could spread the records across a bunch of users instead, but for an integration user or a data load user, that typically isn’t worth the trouble. ⟲

We’re isolating the hot spot from the structures that trigger recalculation. Imagine a user who owns 5 million records being moved in a reorganization. That isn’t moving a box on the org chart; Salesforce may have to re-evaluate access across 5 million records. At this scale, organizational changes become data operations. ⟲

Test knowledge. Know the skew thresholds and the fixes: ownership skew when one user owns more than 10,000 records of an object (no role, or a separate role at the top that doesn’t move, and out of public groups used by sharing rules); parent-child skew at about 10,000 children under one parent. ⟲

Хто має володіти записами, створеними машиною?

Section titled “Хто має володіти записами, створеними машиною? ”

Хто створив запис і хто ним володіє — різні запитання. Redrock надсилає 500 000 доставок через API, і їх створює інтеграційний користувач. Чи має він володіти ними вічно? Можливо, але не лише тому, що він їх створив. А тепер записи створюють і агенти.

Моя позиція: це залежить від того, чи важить власність для спільного доступу. Інтеграційний користувач чи користувач агента — повноцінні користувачі й можуть володіти записами. Якщо власність керує доступом до цього об’єкта (через ієрархію ролей чи правила спільного доступу), призначте записи власникові, якого потребує бізнес: справжньому користувачеві, черзі там, де об’єкт її підтримує, або спеціальному користувачеві-власнику. Якщо власність не керує доступом, залишити власником агента чи інтеграційного користувача може бути кращим вибором, бо слід аудиту веде прямо до того, що створило запис. У будь-якому разі вирішіть, що означає Owner для цього об’єкта, а не механічно перепризначайте кожен машинний запис лише тому, що зазвичай записами володіють люди. І пам’ятайте, що Created By нікуди не дівається: перепризначення власності не стирає того, що запис створила інтеграція. Created By і Owner відповідають на різні запитання. Змусити одне поле відповідати на обидва — так ви й отримуєте погану модель.

Перекіс lookup

Section titled “Перекіс lookup ”

A lookup can be a hot spot too: millions of records pointing at the same location, category, reference record or configuration record. Salesforce’s own training defines it: “Lookup skew happens when a very large number of records are associated with a single record in the lookup object” (Large Data Volumes: Design Your Data Model (відкривається в новій вкладці)). The danger isn’t “lots of lookups.” It’s concentration combined with activity: if millions of active records reference one record, and transactions keep touching that relationship, operations start colliding over it. That’s record locking, which chapter 11 covers. For now, recognize the shape: many active records, one heavily referenced record, worth inspecting. ⟲

Не кожен перекіс однаково небезпечний

Section titled “Не кожен перекіс однаково небезпечний ”

Не запам’ятовуйте «10 000 = погано». П’ятдесят тисяч історичних записів, що вказують на довідкове значення, яке ніколи не змінюється, без ролі в спільному доступі й майже без одночасної активності, можуть бути цілком нормальними. Двадцять тисяч активних записів під батьківським, який часто змінюється, керує спільним доступом, живить roll-up і по якому одночасно б’ють кілька інтеграцій, — зовсім інша історія. Обсяг має форму, і перекіс теж. Скільки записів туди сходиться? Як часто вони змінюються? Чи змінюється батьківський запис? Чи керує зв’язок спільним доступом або блокуванням? Чи оновлюють інтеграції дочірні записи одночасно? Чи запускає перенесення власника або батьківського запису перерахунок? Число каже мені, куди дивитися; поведінка каже, наскільки хвилюватися.

Steve Trucking: де гарячі точки?

Section titled “Steve Trucking: де гарячі точки? ”

На п’ять років ми прогнозували приблизно 9 мільйонів робочих замовлень. Припустімо, хтось каже: «Нехай інтеграційний користувач володіє кожною доставкою». Дев’ять мільйонів записів, один власник. Чи важить власність для спільного доступу до доставок? Якщо ні, спеціальний власник великих обсягів може спрацювати, ізольований від ієрархії ролей і груп правил спільного доступу, як описано вище. Якщо так, один інтеграційний власник — хибна бізнес-модель: інтеграція створює запис, але це не означає, що вона має ним володіти.

Then the Retail Partner. Every work order carries its partner, deliberately, because partner isolation matters. But if one partner is 40% of the business, five years of deliveries is about 3.6 million work orders under one partner account. Does that make the relationship wrong? No. The business relationship is real, and I’m not going to invent 400 fake Redrock accounts because I don’t like the count. But I am going to look for a split the business would recognize. Each partner has real distribution centers, so a child account per DC under the partner spreads the work orders nine or more ways while every account still means something. Add archiving completed deliveries after the claims window, and the active children per parent stay low. ⟲

У цьому різниця між двома виправленнями. «Unassigned Contacts» уже був штучним, тож поділ на пул не втрачає жодного змісту. Redrock — справжній партнер; поділ на Redrock 001, 002 і 003 зіпсував би модель. Поділ за його справжніми DC — ні. Виправлення заради масштабу все одно мають зберігати зміст. Іноді відповідь — інший зв’язок, стратегія спільного доступу, шаблон запитів, модель зберігання чи політика архівування, але ніколи не фальшива ідентичність для справжньої бізнес-сутності.

Steve Trucking's hot spots Steve Trucking's hot spots, a slice of the delivery core. Work Order, 9 million in five years, sits in the middle. It points to a child account per DC, the split the business knows, which is a child of the largest Retail Partner, marked amber: 3.6 million work orders, inspect. An integration or agent user, also amber, owns the work orders: owns all 9 million? Inspect. Each work order contains Work Order Line Items, about 1.6 each: no hot spot. Underneath: inspect, not bad; split a real partner by its real DCs, never into fake copies. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.28.0", "built": "2026-10-15", "id": "DGM-DA-LDV-22", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "object-model/conceptual 1.8.0", "theme": "stevetecharc 1.4.0"} child of is for contains owns Largest Retail Partner 3.6 million work orders: inspect A child account per DC the split the business knows Work Order 9 million in five years Work Order Line Item 1.6 per work order: no hot spot Integration or agent user owns all 9 million? inspect Inspect, not bad. Split a real partner by its real DCs, never into fake copies. © 2026 Twinshark LLC · stevetecharc.com
Натисніть, щоб збільшити

Inspect, not bad. Concentration matters, not the total. ⟲

Знайдіть гарячі точки на діаграмі

Section titled “Знайдіть гарячі точки на діаграмі ”

Ось вправа, яку я люблю. Візьміть модель даних і подивіться на стрілки, а не лише на об’єкти. Для кожного зв’язку спитайте: скільки записів може накопичитися з цього боку стрілки? Потім спитайте те саме про Owner. А тепер уявіть три роки, п’ять, десять. Де концентруються записи? Часто саме там і ховається завтрашня проблема.

За межами іспиту: що змінює ШІ. Людина може створювати 20 записів на день; агент — тисячі. Дайте агентові власного користувача, залиште всі записи в його власності, і перекіс власності з’явиться набагато швидше, ніж будь-коли з людьми. Власність агента — не помилка, але вирішіть, що означає Owner для записів, створених агентами, перш ніж обсяг зробить значення за замовчуванням частиною архітектури.

Що тут вирішує архітектор

Section titled “Що тут вирішує архітектор ”
  • Де зв’язки «батько–нащадок», власності чи lookup концентрують записи і чи досить вони активні, щоб стати гарячими точками.
  • Чи залишаються записи, створені машиною, у власності інтеграційного користувача чи агента, чи їх перепризначають, бо власність керує доступом.
  • Як власників великих обсягів записів ізолюють від ієрархії ролей і груп правил спільного доступу.
  • Коли штучний батьківський запис можна розділити на пул, а коли справжній зв’язок потребує змістовного поділу.
  • Whether each master-detail relationship stays under about 10,000 children per parent at projected volume, or should be a lookup. ⟲

Мільйон записів, розподілених між тисячами власників і батьківських записів, поводиться зовсім інакше, ніж мільйон записів, що вказують в одне місце. Шукайте гарячі точки рано: власники, батьківські записи, lookup — будь-де, де сходиться «кількість нулів». Мета не в тому, щоб позбутися кожного великого зв’язку; деякі з них правильно відображають бізнес. Мета — знати, куди йде трафік, перш ніж відкривати автостраду, бо коли мільйони записів уже прямують до одного виїзду, змінити дорогу значно важче.

Додаткові матеріали

Section titled “Додаткові матеріали ”