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 sentencias SQL mientras que el conector SSAS usa consultas MDX o DAX. Son dos cosas diferentes.

3. Puede ver en mi prueba que la declaración SQL se envía al lado de SQL Server.

¡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)

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

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

En lugar de eso, genera una consulta como esa, seleccione * de tbl, luego extraiga todo el conjunto de resultados en su propio lado, luego ordene por él LOL, luego obtenga 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 solucionarlo fácilmente.

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

Utilizo 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 en el backend. SQL Server no es compatible con DAX. Si traducimos una fórmula DAX, que no podemos esperar, a una declaración SQL, no creo que esto 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 en gris. Por lo tanto, sería una buena idea enviar el trabajo al servidor que ya realiza el trabajo. 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 reciba los valores devueltos debido a la otra medidas. Esto es claramente ineficaz.

¡Atentamente!

Valle

Hola @ AlexS__0001,

He descubierto que power bi inicialmente envía una consulta solo como medida de cálculo. Después de obtener los valores de medida, toma la parte superior N y nuevamente envía una consulta con la cláusula where «nombre de columna en (valor 1, valor2,…., Valor n). Por lo tanto, al final buscaría solo las n filas superiores.

Incluso no he encontrado una manera de hacerlo funcionar como usted pidió, es decir, tener «seleccionar top (n)».

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

Gracias !

También estoy bastante interesado en 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 función de filtrado TopN de Power BI en este caso

No genera consultas así (como se esperaba😞

seleccione top (100) * de tbl order by Site_Url

Se genera así

seleccionar * de tbl

Y luego extrae TODO el conjunto de resultados, luego ordena por 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 característica, Power BI no tiene sentido. Todos los productos concurrentes pueden hacerlo de manera eficiente.