Sesgo de propiedad, de padre y de búsqueda

🌐 También en 19 idiomas

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

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés Esta sección cambió en inglés y aún no se ha vuelto a traducir. (6)

Módulo 2 de 4 del capítulo Diseñar para la escala, capítulo 7 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Cuando el volumen lo cambia todo · Siguiente: El volumen se encuentra con el modelo de uso compartido

La pregunta que responde este módulo: ¿qué pasa cuando demasiados registros apuntan a una sola cosa?

Los problemas de gran volumen de datos no siempre consisten en tener demasiados registros. A veces consisten en tener demasiados registros conectados a lo mismo: un propietario, una cuenta, un padre, un valor de búsqueda. Piensa en el tráfico. Una ciudad puede tener millones de coches y seguir funcionando. El problema empieza cuando todos toman la misma salida de la autopista a las cinco de la tarde. El total importa, y también la concentración. Yo llamo a estas concentraciones puntos calientes; Salesforce las llama sesgo de datos (data skew). Hay varios tipos, y una idea debajo de todos: demasiada actividad que converge en un solo punto del modelo.

Sesgo padre-hijo

El más fácil de imaginar. Una cuenta con 100 contactos: nada raro. Mil: probablemente bien. Diez mil: ahora presto atención. Mi regla de diseño es no más de unos 10.000 hijos bajo un solo padre, y la recomendación de Salesforce traza la misma línea: “un gran número de registros secundarios (10.000 o más) con una sola cuenta principal” es una causa habitual de mal rendimiento (Parent-Child Data Skew (se abre en una pestaña nueva)). El propio ejemplo de Salesforce muestra por qué. Pon 300.000 contactos bajo una cuenta. Un usuario que puede ver uno de esos contactos obtiene acceso implícito a la cuenta. Cuando ese usuario pierde el acceso al contacto, Salesforce tiene que revisar los otros 299.999 contactos antes de poder decidir si retira el acceso del usuario a la cuenta. Haz eso para muchos usuarios a la vez y sale caro. Salesforce también nombra una manera de quitar parte de ese coste: donde tus requisitos de seguridad lo permitan, configura el objeto hijo como Controlado por principal (Controlled by Parent), para que no haya registros de uso compartido implícito del padre que mantener (misma fuente). En la práctica, es el sesgo más común que veo, y he visto a usuarios notar un retraso visible con unos 20.000 hijos bajo un solo padre. Dónde lo nota alguien depende de lo que esté haciendo el sistema. Por eso 10.000 es un umbral de diseño, no una promesa de que el registro 10.001 rompa algo. La verdadera pregunta es: ¿por qué todos estos registros apuntan al mismo padre?

Clic para ampliar

Paso 1 de 2: todas las líneas apuntan a una cuenta. Ese es el punto caliente.

La cuenta “Sin asignar” y los grupos de cuentas

El caso clásico son los contactos sin una cuenta real. Alguien decide que cada contacto necesita una cuenta, así que crea Contactos sin asignar (Unassigned Contacts) y pone ahí todos los contactos sin cuenta. Problema resuelto, hasta que hay 300.000 contactos debajo. Creamos un punto caliente artificial porque el modelo nos obligaba a poner todo en algún sitio, y la relación ni siquiera tiene un significado de negocio. Funcionaba de maravilla con 500 registros. Luego el Número de Ceros lo alcanzó.

¿Qué haces cuando tienes un millón de contactos debajo? He visto cuentas hijas por estado, una cuenta de contactos sin gestionar por estado. He visto una versión automática: cada vez que una cuenta llega a 10.000, se crea otra. Puede resultar un poco incómodo, pero reparte la carga.

Una respuesta es un grupo de cuentas (account pool): Contactos sin asignar 001, 002, 003 y así sucesivamente, con los hijos repartidos entre ellas, cada una por debajo del umbral. Funciona, y es el propio consejo de Salesforce: “Distribuye los registros secundarios para que ningún padre tenga más de 10.000 registros secundarios”, y para los contactos sin cuentas reales, “configura varias cuentas ficticias y distribuye los contactos entre ellas” (Best Practices for Deployments with Large Data Volumes: General (se abre en una pestaña nueva), Winter ‘27). Pero esas no son cuentas reales; son artefactos de arquitectura. Los usuarios preguntarán quién es “Contactos sin asignar 017” y por qué aparece en sus resultados de búsqueda. Así que cuando uso un grupo, oculto los padres de relleno de las experiencias normales de negocio todo lo que puedo. Es un compromiso recurrente: a veces la escala obliga a una estructura que existe para la plataforma, no para el negocio. Cuando ocurre, no finjas que son datos de negocio. Ponle nombre, documéntala y ocúltala donde corresponda.

Clic para ampliar

Paso 2 de 2: los mismos contactos, repartidos en un grupo. Nada se movió salvo hacia dónde apuntan.

Principal-detalle con volumen

Los contactos bajo una cuenta son una búsqueda. Principal-detalle es otra decisión, y la tomas en el modelo de datos, mucho antes de que lleguen los registros. Esta es la pregunta que hago en clase: ¿tendría alguna vez una factura más de 10.000 partidas? No, nunca. Así que una factura y sus líneas pueden ser principal-detalle sin ningún problema. Ahora haz la misma pregunta de cada relación principal-detalle que estés a punto de construir: con el volumen que esperamos, ¿pasará algún padre alguna vez de 10.000 hijos?

Salesforce traza la misma línea: “Como buena práctica, no superes los 10.000 registros secundarios en una relación principal-detalle” (Consideraciones sobre las relaciones de objetos (se abre en una pestaña nueva)). Principal-detalle es la relación más fuerte que te da Salesforce, y precisamente por eso importa la cifra. El registro de detalle no tiene propietario propio; su acceso lo controla el padre. Borra el padre y todos los hijos se van con él. Un hijo no puede pasar a otro padre salvo que hayas permitido el cambio de padre. Los resúmenes acumulados del padre tienen que mantenerse al día a medida que cambian los hijos. Y guardar un hijo puede bloquear al padre, por eso el consejo de Salesforce para las cargas es agrupar los registros secundarios por su padre “para minimizar los conflictos de bloqueo” (Loading Data from the API (se abre en una pestaña nueva)). Con diez hijos, nada de eso se nota. Con cien mil, se nota todo.

Además es difícil de deshacer. Una relación principal-detalle solo puede convertirse en una búsqueda cuando el padre no tiene campos de resumen acumulado, y convertirla cambia el uso compartido del hijo a Lectura/Escritura pública (misma fuente). Para cuando el volumen te dice que fue la decisión equivocada, puede que la relación esté sosteniendo informes, uso compartido y automatización. Cuenta los hijos antes de elegir la relación.

Steve Trucking tiene una de estas decisiones en su modelo. Cada socio minorista (Retail Partner) envía un manifiesto (Manifest__c, un objeto personalizado) por cada centro de distribución, por cada día laborable. Manifest es personalizado, así que se permite principal-detalle con la cuenta del socio, y es tentador: el manifiesto heredaría el uso compartido del socio, que es exactamente el aislamiento que queremos. Ahora cuenta. Nuestro socio más grande tiene nueve o más centros de distribución: nueve manifiestos por día laborable, unos 2.700 al año. Más de 10.000 en menos de cuatro años, bajo un solo padre, y cada manifiesto se revisa durante el día, así que cada revisión tocaría la cuenta del socio. Por eso el modelo hace de Manifest una búsqueda y gestiona el acceso del socio mediante el uso compartido. La factura se mantiene pequeña; los manifiestos siguen llegando.

Clic para ampliar

Paso 1 de 2: principal-detalle, donde el padre sigue siendo pequeño.

Clic para ampliar

Paso 2 de 2: una búsqueda, donde los hijos siguen llegando.

Vigila también Account con sus contactos y oportunidades. No es principal-detalle, pero se comporta como un seudo principal-detalle, con uso compartido implícito hacia el padre, por eso la recomendación de 10.000 aparece ahí también. Nada de esto significa no usar nunca principal-detalle a escala. Significa no elegir una relación fuertemente acoplada y luego sorprenderse de que los registros estén fuertemente acoplados.

Conocimiento para el examen. Conoce la recomendación de 10.000 hijos para principal-detalle y lo que trae principal-detalle con volumen: sin propietario en el detalle (el acceso lo controla el padre), borrado en cascada, sin cambio de padre salvo que se permita, resúmenes acumulados y bloqueo del padre al guardar los hijos. Convertirla en una búsqueda exige que no haya resúmenes acumulados en el principal.

Sesgo de propiedad

Ahora el propietario. Le pregunto a la sala: ¿quién es propietario de un millón de registros? ¿El administrador? ¿Está el administrador ahí sentado creando un millón de registros? Normalmente es el usuario de integración o el usuario de carga de datos. Los registros llegan y nadie sabe a quién asignárselos. Creamos un usuario de integración, crea registros, nadie piensa en la propiedad (“es solo el usuario de integración”) y un año después ese usuario es propietario de 2 millones de registros. Salesforce lo llama sesgo de datos de propiedad (ownership data skew) cuando un usuario es propietario de más de 10.000 registros de un objeto, y el ejemplo clásico son todos los prospectos sin asignar aparcados en un usuario ficticio (Ownership Data Skew (se abre en una pestaña nueva)). Eso no significa que un usuario nunca pueda ser propietario de más. Significa entender las consecuencias: la propiedad no es un sello de Creado por. Mueve la jerarquía de funciones, las reglas de uso compartido y el recálculo: entre bastidores, Salesforce mantiene registros de uso compartido de los registros del propietario para quienes están por encima en la jerarquía de funciones. Asocia millones de registros a un propietario situado en lo profundo del modelo de uso compartido y cambiar cualquier cosa de ese propietario sale caro.

La recomendación coincide con lo que enseño en clase. Si unos pocos usuarios deben ser propietarios de un número muy grande de registros, no les asignes ninguna función; si necesitan una, ponlos en una función aparte en la cima de la jerarquía y no los muevas, y mantenlos fuera de los grupos públicos usados como origen de las reglas de uso compartido (misma fuente). Un inconveniente de la función en la cima: ese usuario hereda el acceso a todos los datos propiedad de los usuarios que están por debajo o compartidos con ellos. En su lugar podrías repartir los registros entre un montón de usuarios, pero para un usuario de integración o de carga de datos, normalmente no compensa el esfuerzo.

Estamos aislando el punto caliente de las estructuras que provocan el recálculo. Imagina que un usuario propietario de 5 millones de registros se mueve en una reorganización. Eso no es mover una caja en el organigrama; puede que Salesforce tenga que reevaluar el acceso en 5 millones de registros. A esta escala, los cambios organizativos se convierten en operaciones de datos.

Conocimiento para el examen. Conoce los umbrales de sesgo y sus soluciones: sesgo de propiedad cuando un usuario es propietario de más de 10.000 registros de un objeto (ninguna función, o una función aparte en la cima que no se mueve, y fuera de los grupos públicos que usan las reglas de uso compartido); sesgo padre-hijo con unos 10.000 hijos bajo un solo padre.

¿Quién debería ser propietario de los registros creados por máquinas?

Quién creó un registro y quién es su propietario no son la misma pregunta. Redrock envía 500.000 entregas a través de la API, y el usuario de integración las crea. ¿Debería ser su propietario para siempre? Quizá, pero no solo porque las creó. Y ahora los agentes también crean registros.

Mi posición: depende de si la propiedad importa para el uso compartido. El usuario de integración o de agente es un usuario válido y puede ser propietario de registros. Si la propiedad determina el acceso en ese objeto (mediante la jerarquía de funciones o las reglas de uso compartido), asigna los registros al propietario que requiere el negocio: un usuario real, una cola si el objeto la admite, o un usuario propietario dedicado. Si la propiedad no determina el acceso, mantener al usuario del agente o de integración como propietario puede ser la mejor opción, porque la pista de auditoría lleva directamente a lo que creó el registro. En cualquier caso, decide qué significa Propietario para este objeto, en lugar de reasignar mecánicamente cada registro creado por máquinas porque normalmente los registros son de personas. Y recuerda que Creado por sigue ahí: reasignar la propiedad no pierde el hecho de que lo creó la integración. Creado por y Propietario responden a preguntas distintas. Hacer que un solo campo responda a las dos es como se llega a un mal modelo.

Sesgo de búsqueda

Una búsqueda también puede ser un punto caliente: millones de registros que apuntan a la misma ubicación, categoría, registro de referencia o registro de configuración. La propia formación de Salesforce lo define: “El sesgo de búsqueda se produce cuando un número muy grande de registros está asociado a un único registro del objeto de búsqueda” (Large Data Volumes: Design Your Data Model (se abre en una pestaña nueva)). El peligro no son “muchas búsquedas”. Es la concentración combinada con la actividad: si millones de registros activos hacen referencia a un registro y las transacciones no dejan de tocar esa relación, las operaciones empiezan a chocar por él. Eso es el bloqueo de registros, que trata el capítulo 11. Por ahora, reconoce la forma: muchos registros activos, un registro muy referenciado, algo que merece la pena inspeccionar.

No todos los sesgos son igual de peligrosos

No memorices “10.000 = malo”. Cincuenta mil registros históricos que apuntan a un valor de referencia que nunca cambia, sin papel en el uso compartido y casi sin actividad concurrente, pueden estar bien. Veinte mil registros activos bajo un padre que cambia a menudo, que determina el uso compartido, alimenta campos de resumen acumulativo y recibe golpes de varias integraciones a la vez es una historia muy distinta. El volumen tiene forma, y el sesgo también. ¿Cuántos registros convergen ahí? ¿Con qué frecuencia cambian? ¿Cambia el padre? ¿La relación determina el uso compartido o el bloqueo? ¿Las integraciones actualizan los hijos de forma concurrente? ¿Mover al propietario o al padre dispara un recálculo? El número me dice dónde mirar; el comportamiento me dice cuánto preocuparme.

Steve Trucking: ¿dónde están los puntos calientes?

A cinco años proyectamos unos 9 millones de órdenes de trabajo. Supongamos que alguien dice: “Que el usuario de integración sea propietario de todas las entregas”. Nueve millones de registros, un propietario. ¿Importa la propiedad para compartir las entregas? Si no, un propietario dedicado de gran volumen puede funcionar, aislado de la jerarquía de funciones y de los grupos de las reglas de uso compartido como vimos arriba. Si importa, un único propietario de integración es el modelo de negocio equivocado: la integración crea el registro; eso no significa que deba ser su propietario.

Luego el socio minorista. Cada orden de trabajo lleva su socio, a propósito, porque el aislamiento de los socios importa. Pero si un socio es el 40 % del negocio, cinco años de entregas son unos 3,6 millones de órdenes de trabajo bajo una sola cuenta de socio. ¿Hace eso que la relación sea incorrecta? No. La relación de negocio es real, y no voy a inventar 400 cuentas falsas de Redrock porque no me guste la cifra. Pero sí voy a buscar una división que el negocio reconozca. Cada socio tiene centros de distribución reales, así que una cuenta hija por centro de distribución bajo el socio reparte las órdenes de trabajo nueve o más veces y cada cuenta sigue significando algo. Añade el archivado de las entregas completadas tras el plazo de reclamaciones, y los hijos activos por padre se mantienen bajos.

Esa es la diferencia entre las dos soluciones. “Contactos sin asignar” ya era artificial, así que dividirlo en un grupo no pierde significado. Redrock es un socio real; dividirlo en Redrock 001, 002 y 003 corrompería el modelo. Dividirlo en sus centros de distribución reales no lo hace. Las soluciones de escala también tienen que preservar el significado. A veces la respuesta es otra relación, otra estrategia de uso compartido, otro patrón de consulta, otro modelo de almacenamiento u otra política de archivado, nunca una identidad falsa para una entidad de negocio real.

Clic para ampliar

Inspeccionar, no condenar. Importa la concentración, no el total.

Encuentra los puntos calientes en el diagrama

Este es un ejercicio que me gusta. Toma el modelo de datos y mira las flechas, no solo los objetos. Para cada relación, pregunta: ¿cuántos registros pueden acumularse en este lado de la flecha? Luego pregunta lo mismo sobre el Propietario. Ahora imagina tres años, cinco, diez. ¿Dónde se concentran los registros? A menudo es ahí donde se esconde el problema de mañana.

Más allá del examen: lo que cambia la IA. Una persona puede crear 20 registros al día; un agente podría crear miles. Dale a un agente su propio usuario, deja que sea propietario de todos sus registros, y el sesgo de propiedad aparece mucho más rápido que nunca con personas. Que un agente sea propietario no está mal, pero decide qué significa Propietario para los registros creados por agentes antes de que el volumen convierta el valor por defecto en parte de la arquitectura.

Lo que decide aquí un arquitecto

• Dónde las relaciones padre-hijo, de propiedad o de búsqueda concentran registros, y si tienen suficiente actividad para convertirse en puntos calientes.
• Si los registros creados por máquinas siguen siendo del usuario de integración o de agente, o se reasignan porque la propiedad determina el acceso.
• Cómo se aíslan los propietarios de gran volumen de la jerarquía de funciones y de los grupos de las reglas de uso compartido.
• Cuándo un padre artificial puede repartirse en un grupo, y cuándo una relación real necesita en cambio una división con significado.
• Si cada relación principal-detalle se mantiene por debajo de unos 10.000 hijos por padre con el volumen previsto, o si debería ser una búsqueda.

Un millón de registros repartidos entre miles de propietarios y padres se comporta de forma muy distinta a un millón de registros que apuntan a un solo sitio. Busca pronto los puntos calientes: propietarios, padres, búsquedas, cualquier lugar donde converja el Número de Ceros. El objetivo no es eliminar toda relación grande; algunas representan correctamente el negocio. Es saber hacia dónde va el tráfico antes de abrir la autopista, porque cuando millones de registros se dirigen a la misma salida, cambiar la carretera se vuelve mucho más difícil.

Explora

• Salesforce Developers, Best Practices for Deployments with Large Data Volumes, Loading Data from the API (se abre en una pestaña nueva) (Winter ‘27): group child records by parent to minimize locking conflicts, checked 2026-11-01. ⟲
• Salesforce Help, Consideraciones sobre las relaciones de objetos (se abre en una pestaña nueva): no more than 10,000 child records for a master-detail relationship; converting master-detail to lookup, checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew (se abre en una pestaña nueva) and Parent-Child Data Skew (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Developers, Best Practices for Deployments with Large Data Volumes: General (se abre en una pestaña nueva) (Winter ‘27), the 10,000-record owner and parent guidance, checked 2026-11-01. ⟲
• Trailhead, Large Data Volumes: Design Your Data Model (se abre en una pestaña nueva): parent-child, ownership and lookup skew, checked 2026-11-01. ⟲
• Salesforce engineering blog, Managing Lookup Skew to Avoid Record Lock Exceptions (se abre en una pestaña nueva) (2013; older, but still the clearest explanation; checked 2026-11-01). ⟲
• SteveTechArc, Documentos de Salesforce por versión: estas guías, una por año desde Winter ‘16, cada una con una copia archivada.