Power BI Top N no empuja hacia abajo SELECT TOP(N)… ORDER BY col al nivel de SQL Server

Hola @AlexS__0001,

1. Hay TOPN en DAX y TOP n en SQL. ¿Cuál usaste?

2. El conector Sql Server usa instrucciones SQL, mientras que el conector SSAS usa consultas MDX o DAX. Son dos cosas diferentes.

3. Puede ver en mi prueba que la instrucción SQL se envía al lado del servidor SQL.

¡Atentamente!

Valle

Eso no es lo que pregunté.

Para reproducir la situación.

– conectarse a cualquier base de datos SQL desde Power BI en modo de consulta directa

– crear tabla visual con filtración de nivel visual TOP(N)

– consultas de captura, que Power BI genera automáticamente

Verá que el filtro TOPN visual no obliga a Power BI a generar consultas SQL como esa: seleccione parte superior (n) * de tbl ordenar por col.

En lugar de eso, genera una consulta como esa select * from tbl, luego extrae el conjunto de resultados completo en su propio lado, luego ordena por él LOL, luego obtiene las filas superiores (N). Entonces, en el caso de SQL Server, todo el trabajo mencionado se realiza en el lado de Power BI. Es un mal enfoque si trabajo con tablas grandes. Espero que puedas arreglar eso fácilmente.

Pero en el caso de SSAS funciona como se esperaba, baja la expresión topn dax a SSAS y hace todo el trabajo sucio en el lado de SSAS.

Uso ambos enfoques, en el caso de SQL Server tengo el cubo ROLAP, en el caso de SSAS uso el cubo MOLAP…

Hola @AlexS__0001,

1. DAX es compatible con SSAS de forma nativa. Enviar la fórmula DAX al servidor SSAS sería una gran idea, como puede ver desde el backend. SQL Server no es compatible con DAX. Si traducimos una fórmula DAX, que no podemos esperar lo que sería, a una instrucción SQL, no creo que sea eficiente.

Referencia: https://msdn.microsoft.com/en-us/library/gg413422.aspx.

2. El modelo SSAS se define todo en el lado del servidor. No podemos hacer ninguna personalización en Power BI, como podemos ver en la interfaz atenuada. Por lo tanto, sería una buena idea enviar el trabajo al servidor que ya lo hace. Pero es diferente para SQL Server. Si usamos una medida en el campo «Por valor», y si Power BI la traduce a declaraciones SQL y luego la envía al servidor, Power BI tiene que evaluar las medidas (DAX) nuevamente cuando recibe los valores de retorno debido a la otra medidas. Esto es obviamente ineficiente.

¡Atentamente!

Valle

Hola @AlexS__0001,

Descubrí que power bi inicialmente envía una consulta solo calculando la medida. Después de obtener los valores de medida, toma N superior de él y nuevamente envía una consulta con la cláusula where » nombre de columna en (valor 1, valor 2, . . . ., valor n). Por lo tanto, al final solo obtendría las n filas superiores.

Incluso no he encontrado una manera de hacer que funcione como usted pidió, es decir, tener «seleccionar arriba (n)».

Si ha encontrado la respuesta, publíquela aquí.

Gracias !

A mi también me interesa bastante este tema. ¿Alguna actualización sobre esto?

¿Podría olvidarse de SSAS? Power BI + SSAS funcionan bien juntos. Mi pregunta no es sobre SSAS o Power BI + SSAS. Lo mencioné como un ejemplo donde las cosas están funcionando bien. No hables de eso por favor.

Hablemos de SQL Server + Power BI y sobre cómo se implementa la característica de filtración TopN de Power BI en este caso

No genera consultas como esa (como se esperaba😞

seleccione top (100) * de orden tbl por Site_Url

Se genera asi

seleccione * de tbl

Y luego extrae TODO el conjunto de resultados, luego lo ordena en el lado de Power BI y obtiene 100 filas.

Por favor, no me hables de que no se puede implementar. Debe implementarse, porque si intenta usar Power BI en tablas grandes en la vida real sin la función, Power BI no tiene sentido. Todos los productos concurrentes pueden hacerlo de manera eficiente.