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 que exista la asignación de Transformaciones de datos para transformar datos de origen, de modo que todos los puntos de contacto se puedan introducir por separado en objetos de punto de contacto estándar |
| Plataforma | Negocio | ✅ Los generadores de código bajo comprenden los diferentes tipos de campo compatibles con Salesforce y evalúan los requisitos de creación de informes y cifrado antes de seleccionar tipos de datos de campo |
| Plataforma | Negocio | ✅ La colaboración y las implicaciones de 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 | ✅ Se utilizan objetos estándar donde sea posible |
| Plataforma | Estándares de diseño | ✅ Existen estándares y directrices para los que las justificaciones comerciales garantizan 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 de Día 0. Ha planificado los grandes volúmenes de datos que a menudo necesitan migrarse 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 al mismo tiempo. |
| 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 | Negocio | ✅ Documentó e implementó una estrategia de archivado y purga de datos |
| Plataforma | Negocio | ✅ 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 comerciales |
| 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 aplaza durante grandes cargas de datos. Las automatizaciones de postprocesamiento se posponen hasta después de que terminen grandes cargas de datos. |
| Plataforma | Planes de prueba | ✅ La estrategia de carga de API masiva se prueba en un entorno sandbox de copia completa Cuando planifique 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 | Negocio | ⚠️ Los generadores de código bajo seleccionan tipos de datos sin evaluar los requisitos de creación de informes y cifrado descendentes |
| Plataforma | Negocio | ⚠️ 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 se documentan, están cerca del valor máximo tanto para el tamaño del archivo como para los archivos por ejecución al mismo tiempo |
| 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 | Negocio | ⚠️ No tiene una estrategia de archivado y purga de datos o su estrategia se documentó pero no se implementó |
| Plataforma | Negocio | ⚠️ Las cargas de datos masivos 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 las horas pico de oficina |
| Plataforma | Datos | ⚠️ Las cargas de datos masivos no están limitadas a los datos mínimos necesarios para decisiones comerciales |
| 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 Ejecutar Apex por lotes en paralelo junto con cargas de datos |
| Plataforma | Organización | ⚠️ La selección de una API sin considerar 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 informes dirigen el diseño de la jerarquía de funciones Utilizando requisitos de creación de informes 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ó su estructura de organización en la jerarquía de funciones, creando funciones individuales para cada título en su empresa |