Mejores prácticas. ¿Utilizando el procedimiento almacenado sql frente a la importación de datos desde sql Server?

[AKUMARKC]

Hola

Mi organización acaba de empezar a utilizar el PowerBI y hay algunos desarrollos en marcha. El proveedor que nos está ayudando está escribiendo muchas consultas SQL y procedimientos almacenados, por otro lado, estaba usando la opción de importación para la conectividad de datos. Sería genial si usted da su opinión sobre cuál sería la mejor práctica de la industria y cómo lo está haciendo?

Me pregunto si habría algún problema de rendimiento en el uso de uno u otro.

¡Gracias!

[Element115]

@MikeGIles fascinante! Ha destacado la necesidad de profundizar en SQL Server y aprender técnicas más avanzadas. ¡Pulgares arriba por todas partes! 😁

[Anonymous]

Es posible que su consultor haya estado intentando satisfacer un caso de uso para datos casi en tiempo real, por lo que estaba utilizando una consulta directa donde realiza todas las transformaciones en la base de datos en lugar de PBImport. Y, respetuosamente, @Element115 sólo está considerando un enfoque para ejecutar un procedimiento almacenado en PBI que le obliga a importar. Hay otras maneras en que su consultor y yo sabemos.

[Element115]

¡en efecto! Es la primera vez que veo esto. @MikeGIles ¿Podría explicar qué es @Offset y por qué es necesario?

[Anonymous]

Sin embargo, en algún momento eso no funcionará con consultas concretas. En ese caso, es mejor crear un servidor vinculado y realizar consultas a través del servidor vinculado mediante la técnica OPENROWSET. (Es normal que un serer SQL haya creado un servidor vinculado a sí mismo.) Esta nueva y encantadora consulta, supone que ha creado un servidor vinculado y funciona limpiamente. (Recuerde que la comunidad elimina caracteres del SQL en algún momento, así que descúértelo si es así)
😶

[Anonymous]

Deberá usar un procedimiento que use un parámetro para que funcione como se describe.

[Element115]

@AKUMARKC

Si se ejecutan instrucciones SQL nativas o procedimientos almacenados: el rendimiento dependerá de la configuración de base de datos y su carga.

Si la importación (suponiendo que el tamaño del conjunto de datos no supere el límite de Power BI), una vez importado, el perf depende del motor xVelocity (también conocido como VertiPaq) y de los recursos de la plataforma en la que se ejecuta esto (el escritorio o la nube para Power BI Service). Pero si está dentro de los límites de tamaño, una vez que se importa todo, no tendrá el retraso de tiempo que proviene de pasar por encima de la red y el tiempo que tarda la base de datos en devolver el conjunto de resultados o establece cada vez que se pulsa la base de datos para cargar datos adicionales.

Además, tenga en cuenta que 'importar' es solo 1 de los 3 modos disponibles para obtener los datos en Power BI. Los otros 2 son 'composite' y 'DirectQuery'. Y los procedimientos almacenados no se pueden llamar en modo DirectQuery y también hay restricciones en cuanto al tipo y la complejidad de las instrucciones SQL que se pueden usar en el modo DirectQuery.

[Anonymous]

Un enfoque diferente para ejecutar procedimientos almacenados admitirá la consulta directa. Considere la posibilidad de crear un DQ con algo como esto como su instrucción SQL:
DECLARA @return_value INT
EXEC @return_value á pbi. Delightful_Prodcedure @Offset -7
SELECT 'Return Value' - @return_value;

[Anonymous]