Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Rendimiento de Dataverse: modelos de datos escalables con esquema ligero, relaciones inteligentes e índices (Doblaje IA)

Transcript

Rendimiento de Dataverse: modelos de datos escalables con esquema ligero, relaciones inteligentes e índices (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Speaker 2: Listo para 10 días de Microsoft 365, Copilot, IA, Azure
0:04
Speaker 2: y las personas que están dando forma al futuro del trabajo.
0:07
Speaker 2: Este enero, M365, con regreso y venimos con más fuerza.
0:11
Speaker 2: Y venimos con más fuerza. Únete a nosotros para sesiones
0:14
Speaker 2: en vivo, demostraciones reales y conocimientos prácticos de MVP y
0:16
Speaker 2: expertos de la industria de todo el mundo. Nada de
0:19
Speaker 2: diapositivas genéricas ni tecnicismos interminables. Abordaremos los desafíos reales. Copilot Studio,
0:24
Speaker 2: agentes de IA Fabric, seguridad, gobernanza y automatización. Ya seas
0:30
Speaker 2: profesional de TI, desarrollador o líder empresarial, hay sesiones diseñadas
0:34
Speaker 2: para ti. Con 10 días completos, puedes explorar múltiples tecnologías
0:38
Speaker 2: y conectar con una comunidad global. Mira las sesiones en
0:41
Speaker 2: vivo y lleva ideas prácticas de vuelta a tu organización.
0:45
Speaker 2: Enero de 2027. 10 días. Una sola comunidad de Microsoft.
0:49
Speaker 2: El registro ya está abierto. Ve a m365com.net y asegura
0:54
Speaker 2: tu lugar hoy mismo. Eso es m365com.net. Únete ahora a m365con.net
1:03
Speaker 2: y nos vemos en vivo en enero.
1:05
Speaker 3: Qué tal si la razón por la que tu aplicación
1:07
Speaker 3: de Ataver se vuelve lenta no es el tamaño de
1:08
Speaker 3: tus datos, sino cómo están configuradas tus relaciones? Hoy vamos
1:13
Speaker 3: a analizar la conexión oculta entre el diseño del esquema
1:16
Speaker 3: y la capacidad de respuesta y por qué tantos creadores
1:19
Speaker 3: de Power Platform se condenan a un bajo rendimiento desde
1:22
Speaker 3: el primer día. Las trampas de rendimiento ocultas en tus
1:26
Speaker 3: tablas¿ Alguna vez te has preguntado por qué una tabla
1:29
Speaker 3: con solo unos pocos miles de filas se siente más
1:31
Speaker 3: lenta que una con un millón con un millón? Es
1:33
Speaker 3: uno de esos momentos en los que tu instinto te
1:35
Speaker 3: dice que debería estar bien, pero Dataverse actúa como si
1:37
Speaker 3: se moviera a través de cemento fresco. La sorprendente verdad
1:40
Speaker 3: es que no es el tamaño bruto lo que ralentiza
1:42
Speaker 3: tu aplicación, sino la forma en que se diseñó la
1:44
Speaker 3: tabla desde el principio. Y esas decisiones de diseño comienzan
1:48
Speaker 3: a causar problemas mucho antes de que alcanzas los límites
1:50
Speaker 3: reales de la plataforma. Muchos creadores culpan a factores externos.
1:54
Speaker 3: asumen que su inquilino está limitado, que la red es inestable,
1:56
Speaker 3: o que hay algún cuello de botella de almacenamiento oculto
1:59
Speaker 3: en el servicio. Pero en muchos casos, esos formularios lentos,
2:03
Speaker 3: búsquedas con retraso y flujos de Power Automate que siguen
2:06
Speaker 3: agotando el tiempo de espera, pueden rastrearse hasta un esquema
2:09
Speaker 3: que parecía perfecto en la fase de construcción, pero que
2:11
Speaker 3: se estructuró de forma que ralentiza cada consulta. Si alguna
2:15
Speaker 3: vez has tenido un usuario quejándose de que Dataverse es
2:17
Speaker 3: lento sin dar contexto, es muy probable que el verdadero
2:20
Speaker 3: culpable sea el diseño de tu tabla, sea el diseño
2:22
Speaker 3: de tu tabla. Piénsalo como un archivador Si cada cajón
2:26
Speaker 3: está lleno de papeles y nada está etiquetado, no importa
2:28
Speaker 3: si solo hay 50 archivos dentro, igual perderás tiempo buscando
2:31
Speaker 3: entre ellos. Una tabla de database funciona de manera repleta
2:35
Speaker 3: de campos que rara vez usas y unida con relaciones
2:37
Speaker 3: innecesarias puede hacer que hasta las operaciones de datos más
2:39
Speaker 3: simples se vuelvan lentas. Se vuelvan lentas. Y a diferencia
2:42
Speaker 3: de un armario desordenado, aquí el desorden no es visible
2:44
Speaker 3: de inmediato para ti ni para el usuario. El único
2:47
Speaker 3: síntoma es una penalización de rendimiento acumulado. He visto proyectos
2:50
Speaker 3: donde el esquema de la tabla parecía una recopilación de
2:52
Speaker 3: todos los pedidos de cada interesado. Necesitas un campo para
2:56
Speaker 3: notas internas en tres formatos distintos. Hecho. Una docena de
2:59
Speaker 3: variaciones de la misma búsqueda por si alguien la necesita
3:01
Speaker 3: más tarde. Agrégalo. Con el tiempo, estos campos se convierten
3:04
Speaker 3: en un peso muerto. Se indexan innecesariamente, ralentizan las inserciones
3:08
Speaker 3: y actualizaciones y hacen que la interfaz del formulario sea
3:10
Speaker 3: más pesada de lo debido. Un ejemplo real involucraba una
3:14
Speaker 3: tabla de clientes con más de 250 campos, la mayoría
3:16
Speaker 3: de los cuales existían por si acaso. El resultado, un
3:20
Speaker 3: formulario que tardaba más de 12 segundos en cargarse con
3:22
Speaker 3: una conexión de alta velocidad. Y esto antes de que
3:25
Speaker 3: cualquier automatización entrara. La propia documentación de Microsoft explica las
3:28
Speaker 3: contrapartidas de la normalización. Según el manual, dividir los datos
3:31
Speaker 3: en muchas tablas pequeñas relacionadas protege contra la redundancia. En
3:35
Speaker 3: la práctica, normalizar en exceso puede perjudicar el rendimiento de
3:38
Speaker 3: Dataverse si las operaciones normales requieren demasiadas uniones entre esas tablas.
3:42
Speaker 3: Cada unión es trabajo adicional para el motor de consultas.
3:45
Speaker 3: Y si tienes columnas que casi nunca cambian almacenadas en
3:47
Speaker 3: tablas relacionadas separadas, estás pagando un costo de procesamiento sin
3:50
Speaker 3: ningún beneficio real, sin ningún beneficio real. Eliminar campos no
3:53
Speaker 3: críticos no es un trabajo glamoroso, pero vale la pena rápidamente.
3:56
Speaker 3: Identifica los atributos que no se usan en informes que
3:58
Speaker 3: rara vez cambian o que duplican información en otra parte.
4:02
Speaker 3: Conserva solo lo que sirve a un proceso actual, no
4:04
Speaker 3: lo que podría necesitarse algún día. Lo mismo ocurre con
4:07
Speaker 3: la anualización. Ahora vale la pena revisar dónde puedes combinar
4:09
Speaker 3: datos relacionados de baja actividad para reducir las uniones. El
4:12
Speaker 3: objetivo no es descartar los buenos principios de diseño, sino
4:14
Speaker 3: encontrar un equilibrio entre la teoría y cómo funciona realmente
4:17
Speaker 3: tu aplicación bajo carga y carga. La realidad es que
4:19
Speaker 3: un rendimiento escalable no se obtiene simplemente añadiendo más recursos
4:22
Speaker 3: a Dataverse. Comienza con el género diseñado por un propósito específico.
4:26
Speaker 3: Las tablas ligeras se ejecutan más rápido, los formularios se
4:29
Speaker 3: cargan de forma más predecible y la automatización se dispara
4:31
Speaker 3: a tiempo incluso a medida que tu entorno crece. Cada
4:34
Speaker 3: campo innecesario o elección de normalización mal pensada añade un
4:38
Speaker 3: poco más de fricción a cada consulta. Con el tiempo
4:42
Speaker 3: esa fricción se suma y provoca un retraso notable. Ahora
4:44
Speaker 3: que el factor del desorden ha salido a la luz...
4:47
Speaker 3: El siguiente desafío se oculta en cómo interactúan tus tablas,
4:50
Speaker 3: y ahí es donde el diseño de relaciones puede determinar
4:52
Speaker 3: el rendimiento. Cuando las relaciones se convierten en obstáculos, algunas
4:57
Speaker 3: relaciones de dataverse parecen cruces en hora punta, parecen hora punta.
5:00
Speaker 3: Todos embotellan un punto y el flujo completo se ralentiza
5:02
Speaker 3: hasta casi detenerse. Sobre el papel, la estructura de datos
5:06
Speaker 3: parece limpia y lógica, pero en la práctica, un solo
5:08
Speaker 3: punto de unión sobrecargado puede dejar inoperante toda una aplicación
5:11
Speaker 3: basada en modelos. Esto no se trata de datos erróneos
5:14
Speaker 3: o volúmenes enormes, sino de cómo están configuradas las relaciones internamente.
5:18
Speaker 3: El diseño de las relaciones puede introducir silenciosamente problemas de
5:21
Speaker 3: rendimiento que solo parecen alcanzar una escala real. Entornos de
5:24
Speaker 3: prueba más pequeños, incluso las uniones ineficientes, funcionan bien. Implementa
5:27
Speaker 3: el mismo diseño en un entorno empresarial con miles de
5:30
Speaker 3: usuarios activos y procesos interconectados, y de repente los formularios
5:33
Speaker 3: tardan segundos en cargar, las subcuadrículas agotan su tiempo de espera,
5:36
Speaker 3: y todo lo que toques hasta las vinculadas se siente lento.
5:41
Speaker 3: Estas no son misteriosas ralentizaciones de la nube, son el
5:44
Speaker 3: resultado natural de relaciones diseñadas para ser claras sin considerar
5:47
Speaker 3: cómo Dataverse ejecuta realmente las consultas. He visto esto de
5:52
Speaker 3: primera mano en un proyecto que usaba una relación de
5:54
Speaker 3: muchos a muchos para vincular contactos a múltiples planes de servicio.
5:58
Speaker 3: En las pruebas iniciales con unos pocos cientos de registros
6:01
Speaker 3: todo funcionaba sin problema. Pero una vez que el conjunto
6:04
Speaker 3: de datos activo creció a cientos de miles y los
6:06
Speaker 3: usuarios consultaban esos enlaces a diario, esa tabla de muchos
6:10
Speaker 3: a muchos se convirtió en la parte más lenta del sistema.
6:12
Speaker 3: Cada carga de formulario activaba unes complejas en tres tablas,
6:16
Speaker 3: y cada unión añadía más sobrecarga hasta que las operaciones
6:19
Speaker 3: básicas tardaban mucho más de lo esperado. El costo oculto
6:23
Speaker 3: no está solo en las en sí mismas. Los campos
6:26
Speaker 3: de búsqueda en Dataverse pueden conllevar comportamientos en cascada como resignaciones,
6:29
Speaker 3: eliminaciones o actualizaciones automáticas de registros que se ejecutan cada
6:32
Speaker 3: vez que cambia el registro vinculado. Aunque son excelentes para
6:36
Speaker 3: mantener los datos sincronizados, también significan más procesamiento en segundo plano.
6:40
Speaker 3: cada vez que ocurre una actualización, incluso para campos no
6:42
Speaker 3: relacionados con la operación principal. En tablas de alta actividad,
6:46
Speaker 3: esas cascadas pueden acumularse rápidamente reduciendo el rendimiento y ralentizando
6:50
Speaker 3: las interacciones sin un disparador visible evidente. La propia guía
6:54
Speaker 3: de Microsoft recomienda evitar uniones complejas innecesarias y por una
6:57
Speaker 3: buena razón. Cada unión adicional en una consulta obliga al
7:01
Speaker 3: motor de Dictaverse a trabajar más, traducir más datos y
7:04
Speaker 3: mantener más información en la memoria mientras se evalúa las condiciones.
7:08
Speaker 3: Esto es manejable en dosis pequeñas, pero una vez que
7:11
Speaker 3: empiezas a superponer múltiples relaciones de muchos a muchos y
7:14
Speaker 3: cascadas en el mismo proceso, el tiempo de ejecución aumenta
7:17
Speaker 3: mucho más rápido de lo que esperarías. Un caso particularmente
7:20
Speaker 3: revelador implicó cambiar una relación de muchos a muchos por
7:23
Speaker 3: una búsqueda única con un campo de opción de apoyo.
7:27
Speaker 3: La lógica de negocio se relaboró ligeramente para que no
7:29
Speaker 3: requiriera resolver dinámicamente múltiples registros vinculados y el resultado fue
7:33
Speaker 3: una reducción inmediata del 80% el tiempo de carga del formulario.
7:38
Speaker 3: Esa mejora no se debió a que el conjunto de
7:40
Speaker 3: datos se redujera o a que el hardware mejorara. Se
7:43
Speaker 3: debió completamente a que se le dio a Dataverse una
7:45
Speaker 3: ruta más sencilla y directa a la información que necesitaba.
7:48
Speaker 3: Los diseños alternativos como planear estructuras también pueden dar sus frutos.
7:52
Speaker 3: A veces, un dato no necesita residir en su propia
7:54
Speaker 3: tabla relacionada dedicada. Si requiere poco mantenimiento y cambia con
7:58
Speaker 3: poca frecuencia, almacenarlo directamente en el registro principal como un
8:01
Speaker 3: campo de opción significa una unión menos a realizar la recuperación.
8:05
Speaker 3: De igual manera, algunas tablas de enlace pueden reemplazarse por
8:08
Speaker 3: campos calculados o acumulados y se usan principalmente para mostrar
8:11
Speaker 3: información resumida. Esto mantiene la capa de presentación rápida y
8:15
Speaker 3: evita operaciones de consulta pesadas en segundo plano. La lección
8:19
Speaker 3: aquí es que el diseño de relaciones no se trata
8:21
Speaker 3: solo de claridad lógica o de cumplir con estándares de normalización.
8:25
Speaker 3: También se trata de comprender el costo de ejecución. Cada
8:28
Speaker 3: tipo de relación que elijas cambia la forma en que
8:30
Speaker 3: Dataverse debe recuperar, combinar y procesar tus datos. Nada. Centrarse
8:35
Speaker 3: solo en la apariencia del esquema sin considerar su funcionamiento.
8:39
Speaker 3: Puede dejarte con una estructura que tiene sentido en papel,
8:41
Speaker 3: pero que es lenta en producción. Aunque optimizar las relaciones
8:47
Speaker 3: elimina gran parte de esa carga de procesamiento, existe otro
8:50
Speaker 3: factor que decide qué tan rápido responde Dataverse, la estrategia
8:53
Speaker 3: de indexación que impulsa esas consultas. La indexación en multiplicador
8:58
Speaker 3: silencioso de rendimiento. Las consultas son tan rápidas como las
9:01
Speaker 3: rutas que pueden tomar, y en Dataverse la indexación decide
9:04
Speaker 3: esa ruta. La mayoría de los creadores saben que existen
9:07
Speaker 3: los índices, pero en la práctica es una de las
9:09
Speaker 3: partes menos comprendidas del ajuste de rendimiento. Puedes tener una
9:13
Speaker 3: estructura de tabla limpia y relaciones optimizadas, pero si Dataverse
9:17
Speaker 3: no puede encontrar rápidamente los registros, todo lo demás se ralentiza.
9:22
Speaker 3: Piensa en ello como intentar encontrar una caja en un
9:24
Speaker 3: almacén enorme. Sin indexación tendrías que recorrer pasillo por pasillo
9:29
Speaker 3: revisando cada estante hasta encontrar la correcta. Eso funciona cuando
9:34
Speaker 3: el almacén es pequeño, pero al escalar a millones de
9:36
Speaker 3: artículos se vuelve absurdo. La indexación es el equivalente a
9:40
Speaker 3: tener un mapa preciso y una ruta directa al estante exacto.
9:43
Speaker 3: Cuanto menos trabajo tenga que hacer Dataverse para localizar un registro,
9:46
Speaker 3: más rápido se ejecutarán las vistas, filtros y automatizaciones. Dataverse
9:50
Speaker 3: crea automáticamente ciertos índices para ti. Principalmente en claves primarias,
9:54
Speaker 3: búsquedas y algunas columnas del sistema. Por eso los entornos
9:58
Speaker 3: nuevos funcionan bien sin indexación manual, pero la indexación automática
10:00
Speaker 3: tiene límites. Las consultas complejas con múltiples condiciones, especialmente en
10:05
Speaker 3: columnas personalizadas, pueden terminar escaneando gran parte de la tabla
10:08
Speaker 3: si no hay un índice específico que las guíe. Ahí
10:12
Speaker 3: es cuando empiezas a ver paneles lentos, retrasos en reportes
10:15
Speaker 3: y vistas de lista que no cargan correctamente. El otro extremo,
10:18
Speaker 3: el exceso de indexación, puede ser igual de malo. Cada
10:21
Speaker 3: vez que insertas, actualizas o eliminas un registro de Dataverse,
10:23
Speaker 3: tiene que mantener todos los índices relevantes. Demasiados índices personalizados
10:28
Speaker 3: pueden aumentar los tiempos de escritura y ralentizar las actualizaciones masivas.
10:33
Speaker 3: El arte aquí es saber qué columnas vale la pena
10:35
Speaker 3: indexar y, algo igual de importante, cuáles no. Los índices
10:39
Speaker 3: son más valiosos en campos usados frecuentemente en filtros, ordenamientos
10:42
Speaker 3: o uniones, no en campos que solo importan, en vistas
10:45
Speaker 3: de formulario ocasionales, Por ejemplo, en una tabla de solicitudes
10:48
Speaker 3: de servicio de alto volumen, los informes tardaban hasta 6
10:50
Speaker 3: segundos solo en devolver una lista filtrada para los gerentes.
10:54
Speaker 3: El problema principal era que el filtrado se realizaba en
10:56
Speaker 3: una columna personalizada de tipo de solicitud sin un índice dedicado.
11:00
Speaker 3: Agregar un índice no agrupado en esa columna redujo inmediatamente
11:03
Speaker 3: el tiempo de consulta a menos de 200 milisegundos. Eso
11:06
Speaker 3: no es una mejora sutil. Cambió por completo la sensación
11:08
Speaker 3: de la aplicación para los usuarios diarios. Lo mejor de
11:11
Speaker 3: todo es que no requirió tocar el modelo de datos
11:13
Speaker 3: real ni la lógica de la interfaz, solo una ruta
11:14
Speaker 3: de recuperación más inteligente. Pero obtener ese beneficio después del
11:18
Speaker 3: hecho no es lo ideal. Adaptar índices en un sistema
11:21
Speaker 3: en vivo conlleva riesgos. Debe probar los impactos en la escritura,
11:26
Speaker 3: programar cambios durante ventanas de poco uso y a veces
11:28
Speaker 3: lidiar con la sobrecarga de migración si la tabla es
11:30
Speaker 3: extremadamente grande. Por el contrario, planificar su estrategia de indexación
11:35
Speaker 3: antes del lanzamiento hace que todo el sistema sea más resistente.
11:38
Speaker 3: Puede emparejar índices con sus consultas más comunes desde el
11:40
Speaker 3: primer día, reduciendo la necesidad de correcciones de rendimiento de
11:43
Speaker 3: emergencia más adelante. Un buen enfoque durante la planificación del
11:46
Speaker 3: esquema es mapear sus consultas de mayor tráfico e identificar
11:48
Speaker 3: en qué campos filtran a menudo. Si sabe que una
11:51
Speaker 3: vista o pantalla de la aplicación siempre se ordenará en
11:53
Speaker 3: una columna particular, considera indexarla desde el principio. Lo mismo
11:57
Speaker 3: para las condiciones de unión relaciones que sabe que son
11:59
Speaker 3: fundamentales para el flujo de trabajo de la aplicación. Luego,
12:01
Speaker 3: revise periódicamente las estadísticas de uso de los índices para
12:04
Speaker 3: encontrar candidatos que puede eliminar porque rara vez se usan
12:06
Speaker 3: en consultas del mundo real. La indexación no es llamativa,
12:10
Speaker 3: y no aparece en la interfaz de usuario como lo
12:11
Speaker 3: hace un nuevo formulario o panel, pero es un multiplicador silencioso.
12:15
Speaker 3: Cada consulta optimizada se beneficia de ella, y cada una
12:18
Speaker 3: mal indexada se convierte en un lastre a medida que
12:20
Speaker 3: crece su conjunto de datos. Una estrategia de indexación eficaz
12:23
Speaker 3: asegura un margen de rendimiento y convierte la ejecución de
12:26
Speaker 3: consultas de un posible coyote en una fortaleza confiable. Pero
12:29
Speaker 3: todavía queda una palanca más por accionar. Para mantener realmente
12:32
Speaker 3: a Dataverse rápido a escala, debe pasar de solucionar los
12:35
Speaker 3: cuellos de botella después de que aparecen a diseñar formas
12:38
Speaker 3: que eviten que se formen. De correcciones reactivas a una
12:42
Speaker 3: arquitectura proactiva. La mayoría de las correcciones de rendimiento en
12:45
Speaker 3: Dataverse se sienten como apagánicen. Un usuario informa sobre formularios
12:48
Speaker 3: lentos o te realiza algunas comprobaciones, hace cambios quirúrgicos y
12:51
Speaker 3: espera que se resuelva.¿ Pero qué pasaría si pudiera construir
12:54
Speaker 3: de una manera que evitara que sus problemas aparecieran por completo?
12:57
Speaker 3: La verdad silenciosa es que las aplicaciones de Dataverse más
12:59
Speaker 3: rápidas y estables no solo están bien ajustadas, no solo
13:01
Speaker 3: están bien ajustadas. Fueron diseñadas desde el primer día pensando
13:03
Speaker 3: en la escalabilidad. La planificación arquitectónica temprana es el impulso
13:07
Speaker 3: de rendimiento más económico que jamás se implementará. No se
13:10
Speaker 3: trata de agregar capas adicionales por si acaso, sino de
13:12
Speaker 3: pensar en cómo se comportarán sus tablas, relaciones e índices
13:16
Speaker 3: cuando la aplicación tenga toda la carga de producción. Sean.
13:21
Speaker 3: En la fase de desarrollo cualquier cambio tiene un costo bajo.
13:24
Speaker 3: Una vez que la aplicación está activa, ese mismo cambio
13:25
Speaker 3: podría implicar refactorizar docenas de flujos, paneles, flujos, paneles y
13:28
Speaker 3: formularios controlados por modelo. La diferencia en el esfuerzo es abismal.
13:31
Speaker 3: He trabajado con equipos que no hicieron pruebas de rendimiento
13:34
Speaker 3: hasta justo antes del lanzamiento. Todo se había construido de
13:36
Speaker 3: forma lógica, se veía limpio en el esquema y funcionaba
13:39
Speaker 3: bien en las pruebas de aceptación de usuario UAT. Pero luego,
13:42
Speaker 3: los informes analíticos empezaron a tardar minutos en cargarse, los
13:45
Speaker 3: flujos de Power Automate expiraban y ciertos formularios solo abrían
13:48
Speaker 3: la mitad de las veces. En un caso, una aplicación
13:51
Speaker 3: de programación principal tuvo que ser desmantelada y reconstruida, porque
13:54
Speaker 3: varias consultas clave dependían de campos sin indexar ocultos en
13:57
Speaker 3: relaciones de muchos a muchos. La reconstrucción retrasó el lanzamiento
14:01
Speaker 3: tres meses y consumió semanas de horas de desarrollo y pruebas.
14:05
Speaker 3: La clave para evitar ese escenario es hacer que el
14:06
Speaker 3: rendimiento sea un requisito de diseño, no una ocurrencia tardía.
14:10
Speaker 3: Eso significa planificar la indexación al mismo tiempo que diseñas
14:13
Speaker 3: las tablas, saber qué campos extraen cada filtro y asegurarte
14:15
Speaker 3: de que estén listos para buscarse eficientemente. Significa resistir la
14:19
Speaker 3: tentación de añadir docenas de campos por si acaso durante
14:22
Speaker 3: el prototipado, ya que cada uno añade peso a los
14:24
Speaker 3: formularios y transacciones. Y significa modelar las relaciones según cómo
14:29
Speaker 3: funcionarán a escala, no solo por lo bien que se
14:31
Speaker 3: vean diagramadas en una sesión de trabajo. Cuando tratas el
14:34
Speaker 3: rendimiento como parte de arquitectura dependes mucho menos de la
14:37
Speaker 3: resolución de problemas tras la implementación. Detectas posibles cuellos de
14:40
Speaker 3: botella cuando todavía es fácil cambiar de dirección. Si un
14:44
Speaker 3: determinado modelo de relación ralentizara las uniones en grandes conjuntos
14:46
Speaker 3: de datos, buscas una estructura alternativa antes de que sustente
14:49
Speaker 3: un sistema en vivo. Si un índice pudiera ser instantáneo
14:51
Speaker 3: en la vista de alto tráfico, lo añades antes de
14:53
Speaker 3: que la vista sea de misión crítica. Eso es mucho
14:55
Speaker 3: más fácil que explicar a los usuarios de negocio por
14:57
Speaker 3: qué su aplicación funciona distinto ahora porque tuviste que arreglar
15:00
Speaker 3: algo que ellos no sabían que estaba roto. Existen herramientas
15:03
Speaker 3: en el ecosistema Microsoft que hacen que esta mentalidad proactiva
15:05
Speaker 3: sea mucho más fácil de aplicar. El comprador de soluciones
15:09
Speaker 3: escaneará tu entorno y señalará patrones que sabe que podrían
15:11
Speaker 3: afectar el rendimiento. Las perspectivas de rendimiento en el centro
15:15
Speaker 3: de administración de Power Platform pueden ayudarte a detectar consultas lentas,
15:18
Speaker 3: rastrear tiempos de carga de formularios e identificar dónde se
15:20
Speaker 3: está retrasando la recuperación o el procesamiento. Ejecutar estas herramientas
15:24
Speaker 3: durante el desarrollo y antes de lanzamientos importantes es lo
15:27
Speaker 3: más cercano a un seguro de rendimiento sin que los
15:28
Speaker 3: usuarios finales se conviertan en los probadores. La recompensa de
15:31
Speaker 3: trabajar de esta manera es sencilla. Las aplicaciones creadas con
15:35
Speaker 3: un pensamiento de rendimiento proactivo tienden a escalar sin problemas
15:37
Speaker 3: con ajustes mínimos. Cuando el volumen de datos crece, no
15:40
Speaker 3: alcanzan límites inesperados de repente. Cuando se añaden nuevas funciones,
15:44
Speaker 3: nada se detiene por completo porque el diseño original dejó espacio.