Este texto se tradujo utilizando el sistema de traducción automatizado de Salesforce. Realice nuestra encuesta para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación.
Fiable: escalabilidad
Obtenga más información acerca de Confianza bien arquitectónica → Fiable → Escalabilidad → Modelado de datos
| ¿Dónde buscar? Área de producto | Ubicación | ¿Qué aspecto tiene? Patrón |
|---|---|
| Data 360 | Organización | ✅ Las transformaciones de datos se utilizan para desnormalizar datos antes de asignar Transformaciones de datos para transformar datos de origen, de modo que todos los puntos de contacto se pueden ingresar por separado en objetos de punto de contacto estándar |
| Plataforma | Negocios | ✅ Los generadores de código bajo comprenden los diferentes tipos de campo admitidos por Salesforce, y evalúan los requisitos de creación de reportes y cifrado antes de seleccionar tipos de datos de campo |
| Plataforma | Negocios | ✅ Las implicaciones de colaboración y sesgo de datos se evalúan antes de elegir establecer una relación principal-detalle entre objetos |
| Plataforma | Modelo de datos | ✅ Las tablas se han desnormalizado para la escala |
| Plataforma | Modelo de datos | ✅ Los objetos estándar se utilizan donde sea posible |
| Plataforma | Estándares de diseño | ✅ Estándares y directrices para los que las justificaciones de negocio garantizan la existencia de un objeto personalizado |
Obtenga más información acerca de Confianza bien arquitectónica → Fiable → Escalabilidad → Volumen de datos
| ¿Dónde buscar? Área de producto | Ubicación | ¿Qué aspecto tiene? Patrón |
|---|---|
| Data 360 | Planes de prueba | ✅ Los cálculos de carga masiva tienen en cuenta las cargas de datos del Día 0. Ha planificado los grandes volúmenes de datos que a menudo se deben migrar antes de que su solución entre en funcionamiento (también conocido como Día 0) y ha confirmado que no se acercará al tamaño máximo de archivo y al máximo de archivos por ejecución programada de forma simultánea. |
| Plataforma | Apex | ✅ Existe lógica para distribuir el número de registros secundarios entre múltiples registros principales en escenarios donde el sesgo de datos es un problema |
| Plataforma | Apex | ✅ Existe lógica para asignar todos los registros a los usuarios humanos apropiados cuando se importan o replican a través de una integración |
| Plataforma | Negocios | ✅ Documentó e implementó una estrategia de purga y archivado de datos |
| Plataforma | Negocios | ✅ La estrategia de carga de datos masivos está optimizada para optimizar el consumo del servidor Los tiempos de carga, las secuencias de datos, el bloqueo de registros, la automatización y los procesos de colaboración masiva se tienen en cuenta en su estrategia de carga masiva para un consumo eficiente del servidor |
| Plataforma | Datos | ✅ Ningún registro principal tiene más de 10.000 registros secundarios |
| Plataforma | Datos | ✅ No hay usuarios asignados a más de 10.000 registros del mismo tipo de objeto |
| Plataforma | Datos | ✅ No existen instancias donde más de 10.000 registros tengan campos de búsqueda que apunten al mismo registro |
| Plataforma | Datos | ✅ Las cargas de datos masivos en producción no se producen durante el horario laboral pico |
| Plataforma | Datos | ✅ Las cargas de datos masivos se ordenan en lotes según los valores de campo de ParentId |
| Plataforma | Datos | ✅ Las cargas de datos masivos incluyen solo los datos mínimos necesarios para las decisiones de negocio |
| Plataforma | Flujo | ✅ Existe lógica para distribuir el número de registros secundarios entre múltiples registros principales en escenarios donde el sesgo de datos es un problema |
| Plataforma | Flujo | ✅ Existe lógica para asignar todos los registros a los usuarios humanos apropiados cuando se importan o replican a través de una integración |
| Plataforma | Organización | ✅ El postprocesamiento de datos se pospone durante grandes cargas de datos. Las automatizaciones de postprocesamiento se posponen hasta después de que terminen las grandes cargas de datos. |
| Plataforma | Planes de prueba | ✅ La estrategia de carga de API masiva se prueba en un entorno sandbox de copia completa Al planificar una carga de datos utilizando la API masiva en un entorno sandbox de copia completa para identificar el patrón, la secuencia de carga y cualquier problema de bloqueo que pueda surgir. |
Obtenga más información acerca de Confianza bien arquitectónica → Fiable → Escalabilidad → Modelado de datos
| ¿Dónde buscar? Área de producto | Ubicación | ¿Qué evitar? Antipatrón |
|---|---|
| Plataforma | Negocios | ⚠️ Los generadores de código bajo seleccionan tipos de datos sin evaluar los requisitos de creación de reportes y cifrado descendentes |
| Plataforma | Negocios | ⚠️ La colaboración y el sesgo de datos no se tienen en cuenta antes de establecer relaciones principal-detalle entre objetos |
| Plataforma | Modelo de datos | ⚠️ Se han normalizado las tablas para evitar redundancias |
| Plataforma | Modelo de datos | ⚠️ Tiene objetos estándar replicados |
| Plataforma | Estándares de diseño | ⚠️ No existen estándares para la creación de objetos personalizados |
Obtenga más información acerca de Confianza bien arquitectónica → Fiable → Escalabilidad → Volumen de datos
| ¿Dónde buscar? Área de producto | Ubicación | ¿Qué evitar? Antipatrón |
|---|---|
| Data 360 | Planes de prueba | ⚠️ Sus cálculos de carga masiva no incluyen cargas de datos de Día 0 Los cálculos de carga de Día 0 no se realizan, o si están documentados, están cerca del valor máximo para el tamaño del archivo y los archivos por ejecución de forma simultánea |
| Plataforma | Apex | ⚠️ Los registros creados a través de cargas de datos o integraciones se asignan a un "usuario de integración" genérico |
| Plataforma | Apex | ⚠️ Los registros secundarios se asignan arbitrariamente a registros principales independientemente del número de registros secundarios existentes que ya se asignaron |
| Plataforma | Negocios | ⚠️ No tiene una estrategia de archivado y purga de datos o su estrategia se documentó pero no se implementó |
| Plataforma | Negocios | ⚠️ Las cargas de datos masivas se ejecutan sin planificación para la escala Los tiempos de carga, las secuencias de datos, el bloqueo de registros, la automatización y los procesos de colaboración masiva no se tienen en cuenta antes de realizar cargas de datos masivas |
| Plataforma | Datos | ⚠️ Las cargas de datos masivos en producción se producen durante el horario laboral pico |
| Plataforma | Datos | ⚠️ Las cargas de datos masivos no están limitadas a los datos mínimos necesarios para decisiones de negocio |
| Plataforma | Datos | ⚠️ Existen registros con más de 10.000 registros secundarios |
| Plataforma | Datos | ⚠️ Los usuarios están asignados a más de 10.000 registros del mismo tipo |
| Plataforma | Datos | ⚠️ Existen instancias donde más de 10.000 registros tienen campos de búsqueda que apuntan al mismo registro |
| Plataforma | Datos | ⚠️ Las cargas de datos masivos no se ordenan en lotes según los valores de campo de ParentId |
| Plataforma | Flujo | ⚠️ Los registros creados a través de cargas de datos o integraciones se asignan a un "usuario de integración" genérico |
| Plataforma | Flujo | ⚠️ Los registros secundarios se asignan arbitrariamente a registros principales independientemente del número de registros secundarios existentes que ya se asignaron |
| Plataforma | Organización | ⚠️ La estrategia de carga de API masiva se prueba en un entorno sandbox de copia parcial. Las pruebas de carga de API masiva para determinar los tiempos de carga por lotes se realizan en un subconjunto de datos en un entorno sandbox de copia parcial. |
| Plataforma | Organización | ⚠️ Realización de cargas de datos masivas en paralelo con otras operaciones que bloquean registros Ejecución de Apex por lotes en paralelo junto con cargas de datos |
| Plataforma | Organización | ⚠️ La selección de una API sin tener en cuenta el tamaño de su API de SOAP de conjunto de datos se utiliza para cargas de datos superiores a 500.000 registros |
| Plataforma | Organización | ⚠️ Los requisitos de creación de reportes dirigen el diseño de la jerarquía de funciones Utilizando requisitos de creación de reportes para determinar qué o cuántos niveles de jerarquía de funciones necesita |
| Plataforma | Organización | ⚠️ La jerarquía de funciones tiene funciones vacías Las funciones de marcador de posición vacías se crean para el futuro |
| Plataforma | Organización | ⚠️ La jerarquía de funciones imita su gráfico de organización Replicó la estructura de su organización en la jerarquía de funciones, creando funciones individuales para cada título en su compañía |