Forum Discussion
Helper IPerformance PowerBi. Que es lo mas optimo?
¡Uau! Muchas preguntas geniales. Puede obtener una mejor respuesta si las publica como 3 preguntas separadas, ya que son lo suficientemente diferentes como para que se requiera que diferentes personas las respondan. No tengo todas las respuestas, pero lo intentaré.
1) En mi experiencia, es mejor empujar las transformaciones lo más cerca posible de la fuente. Por lo tanto, crear vistas en SQL y extraerlas en Power BI es lo mejor.
2) Esto es complicado y depende. ¿Qué parte del flujo de datos se utiliza en cada informe? ¿Cuánta superposición hay entre los informes? Tenga en cuenta que cuando se actualiza un flujo de datos, todo debe actualizarse o, si una parte falla, todo falla, por lo que puede ser mejor dividir el flujo de datos en "dimensiones centrales" que se utilizan en la mayoría de los informes, y luego colocar las otras tablas en otro flujo de datos o flujos de datos.
3) ¿Cómo se relaciona el formulario A con el formulario B? Al no conocer los formularios, supongo que el Usuario se relaciona con el Formulario A y el Usuario se relaciona con el Formulario B, pero ese formulario A no se relaciona directamente con el Formulario B. Sin embargo, necesito más detalles sobre los formularios para confirmarlo.
Para los diferentes usuarios (creados por, modificados por, aprobados por, etc.) puede usar la dimensión de juego de roles y las relaciones inactivas, o puede tener una tabla de usuario 'aprobadores' y una tabla de usuarios 'creadores'. Esto también depende del resultado final deseado -
¿quieres ver cuántos formularios creó y aprobó Jorge en el mismo objeto visual? Luego usa las dimensiones de juego de roles
¿O desea filtrar por Jorge como aprobador, y luego filtrar por los creadores en un filtro / visual separado, luego use aprobadores y tablas de usuario separadas de creadores?
AdministratorTal vez esto pueda ayudar para la pregunta 3.
El Formulario A tiene un asociado del Formulario B. Relación 1 a 1.
Ambos tienen un usuario. PERO los usuarios entre ellos pueden ser diferentes.
En mi experiencia puedo hacer esto de 3 maneras.
1- Con una tabla suelta, entonces en las tablas de Formularios puedo usar una columna de cálculo, con algo como esto: Caculate(users_table(user_name), user_table(id) = FormA/B(user_id))
2- Con la tabla duplicada, entonces el usuarioA está relacionado con FormA. Y userB está relacionado con FormB.
3- Con una tabla de usuario y relacionada con ambas entonces, PERO una de las relaciones debe estar inactiva.
Si entiendo correctamente @AllisonKennedy dijiste que si necesito 2 filtros en mis visuales que son para usuarios (en este caso necesitamos eso) la forma correcta duplicará la tabla.
Entiendo que la tabla de usuario generalmente es "pequeña", esta opción tiene sentido.
@Migasuke No sé si entiendo correctamente, pero ¿dijiste que la forma en que mi fuente es una base de datos SQL literalmente es "casi" lo mismo porque el plegado de consultas está optimizado para esta fuente?
Entiendo que si podemos usar la fuente para el proceso ETL, deberíamos usar eso, pero ¿es irrelevante en este caso?
Muchas gracias a ambos.
AdministratorHola @Alexx95 ,
Me temo que no le ayudaré con su tercera pregunta, sin embargo, puedo aclararle una pregunta adicional hacia mí.
Te doy ejemplo de dos escenarios diferentes:
1. Quiero extraer 100K filas de Excel y necesito seleccionar solo las filas de 10K principales.
En Power Query me veo obligado a extraer todas las filas de 100K y luego quitar las 90K restantes de filas.
2. En caso de plegado de consultas, que es posible en Azure SQL, y otro escenario de SQL es diferente.
En Power Query quiero mantener los 10K superiores de 100K. Power Query envía el comando SQL a la base de datos y no descargaré todos los 100K, sino solo 10K. La razón es que la base de datos devolverá datos ya procesados con solo 10K, por lo que la operación se realiza en el lado de la base de datos y no en el lado de Power BI.
Así que el resultado es:
Haga su transformación en la fuente si puede, sin embargo, con las fuentes de plegado de consultas (bases de datos) realmente no importa.