cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
yacoubi
Helper I
Helper I

Rendimiento de la tabla de fechas: SQL vs M vs DAX

Hola. Necesito una tabla de fecha tenue en mi modelo y quiero saber cuál es el preferido y por qué:

  1. Crear tabla en SQL
  2. Crear en M (consulta de potencia)
  3. Crear a través de DAX

Gracias.

1 ACCEPTED SOLUTION
Syndicate_Admin
Administrator
Administrator

@D_PBI gracias por la entrada. Con respecto a su primer punto en SQL, ese caso de uso particular es aplicable para cualquier dimensión / hecho que traiga del sistema back-end. Esa es la naturaleza del trabajo que tiene que hacer si está realizando cambios en su estructura de datos de subrayado, no importa que sea una dimensión de fecha o cualquier otra tabla, por lo que no está completamente de acuerdo con ese punto. La mayoría de las veces este tipo de dimensión, especialmente la dimensión de fecha, está muy bien definida por adelantado y es muy menos probable que haya un cambio en ella, si hay, sí, tiene que abrir cada informe y actualizar el modelo. Planificación y planificación.

En mi experiencia personal, estoy proporcionando soluciones a empresas medianas y grandes durante los últimos 5 años y no recuerdo ninguna instancia en la que haya agregado nuevas columnas en la dimensión de fecha y, por esa misma razón, tengo que actualizar el modelo. No podemos predecirlo todo y por eso se llama mejor práctica, ninguna solución es perfecta.

Sólo mis 2 centavos.

View solution in original post

5 REPLIES 5
Syndicate_Admin
Administrator
Administrator

@D_PBI gracias por la entrada. Con respecto a su primer punto en SQL, ese caso de uso particular es aplicable para cualquier dimensión / hecho que traiga del sistema back-end. Esa es la naturaleza del trabajo que tiene que hacer si está realizando cambios en su estructura de datos de subrayado, no importa que sea una dimensión de fecha o cualquier otra tabla, por lo que no está completamente de acuerdo con ese punto. La mayoría de las veces este tipo de dimensión, especialmente la dimensión de fecha, está muy bien definida por adelantado y es muy menos probable que haya un cambio en ella, si hay, sí, tiene que abrir cada informe y actualizar el modelo. Planificación y planificación.

En mi experiencia personal, estoy proporcionando soluciones a empresas medianas y grandes durante los últimos 5 años y no recuerdo ninguna instancia en la que haya agregado nuevas columnas en la dimensión de fecha y, por esa misma razón, tengo que actualizar el modelo. No podemos predecirlo todo y por eso se llama mejor práctica, ninguna solución es perfecta.

Sólo mis 2 centavos.

View solution in original post

Syndicate_Admin
Administrator
Administrator

@parry2k
Veo que el OP tiene un año de antigüedad ahora, pero solo quiero agregar mis pensamientos, para confirmación o corrección.

1) Aunque la creación de una tabla de dimensión de fecha en SQL significaría que crea / modifica en un solo lugar (por lo que manejar cualquier cambio (s) sólo una vez), que es bueno, es posible que todavía tenga que atender a cualquier cambio en M dependiendo del cambio SQL realizado - es decir, si usted ha añadido una nueva columna de fecha, si usted ha SELECT * FROM esa tabla, a continuación, los pasos aplicados PQ hecho necesidad de manipular para manejar la columna de fecha adicional traído en, lo que significaría todavía tener que abrir cada informe y configurar en consecuencia.

2) Al usar CALENDARAUTO() en DAX, analizará el rango completo de fechas utilizadas en su modelo de datos. Si tuviera que crear la dimensión Dat en SQL o M, tendría que especificar explícitamente las fechas de inicio y finalización que pueden ser dinámicas.
Además, si, por ejemplo, establece el intervalo de fechas para que sea de 19000101 a 19991231 por adelantado, pero, por ejemplo, la fecha de pedido solo contiene fechas entre 19800101 y 19891231, cuando agrega la tabla de dimensión de fecha a un objeto visual para usarlo como segmentador en la fecha de pedido, no mostraría el objeto visual el rango completo de entre 19000101 y 19991231, sin duda el cliente solicitaría solo los valores de fecha de pedido relevantes (es decir, 19800101 a 19891231) en el objeto visual.

3) Si quería una tabla de dimensión de tiempo, la última que supe, esto no se pudo completar con DAX, por lo que tendría que completar esto en SQL o M.

Cualquier comentario (confirmación/corrección/experiencia) sobre lo anterior sería útil.

Syndicate_Admin
Administrator
Administrator

Veo que el OP tiene un año de antigüedad ahora, pero solo quiero agregar mis pensamientos, para confirmación o corrección.

1) Aunque la creación de una tabla de dimensión de fecha en SQL significaría que crea / modifica en un solo lugar (por lo que manejar cualquier cambio (s) sólo una vez), que es bueno, es posible que todavía tenga que atender a cualquier cambio en M dependiendo del cambio SQL realizado - es decir, si usted ha añadido una nueva columna de fecha, si usted ha SELECT * FROM esa tabla, a continuación, los pasos aplicados PQ hecho necesidad de manipular para manejar la columna de fecha adicional traído en, lo que significaría todavía tener que abrir cada informe y configurar en consecuencia.

2) Al usar CALENDARAUTO() en DAX, analizará el rango completo de fechas utilizadas en su modelo de datos. Si tuviera que crear la dimensión Dat en SQL o M, tendría que especificar explícitamente las fechas de inicio y finalización que pueden ser dinámicas.
Además, si, por ejemplo, establece el intervalo de fechas para que sea de 19000101 a 19991231 por adelantado, pero, por ejemplo, la fecha de pedido solo contiene fechas entre 19800101 y 19891231, cuando agrega la tabla de dimensión de fecha a un objeto visual para usarlo como segmentador en la fecha de pedido, no mostraría el objeto visual el rango completo de entre 19000101 y 19991231, sin duda el cliente solicitaría solo los valores de fecha de pedido relevantes (es decir, 19800101 a 19891231) en el objeto visual.

3) Si quería una tabla de dimensión de tiempo, la última que supe, esto no se pudo completar con DAX, por lo que tendría que completar esto en SQL o M.

Cualquier comentario (confirmación/corrección/experiencia) sobre lo anterior sería útil.



v-eachen-msft
Community Support
Community Support

Hola @yacoubi ,

Puede consultar este blog sobre sql, m y DAX:

https://sqlserverbi.blog/2018/05/12/sql-m-or-dax/

"Si tiene un almacenamiento de datos de SQL Server, puede usar SQL para crear tablas de dimensiones de fecha. Por lo general, es mejor unificar todos los datos de informes en el almacén de datos o data mart para crear una única versión de la verdad para la generación de informes. También puede usar herramientas como SSIS o Azure Data Factory para compilar y administrar estos objetos antes de importarlos a Power BI o al modelo de datos de Analysis ServicesAnalysis Services ."

Community Support Team _ Eads
If this post helps, then please consider Accept it as the solution to help the other members find it.
parry2k
Super User
Super User

@yacoubi No creo que importe, pero si puede hacerlo en el origen como sql, puede usar la misma vista/tabla en varios informes, pero con DAX y M, debe asegurarse de hacer este paso en cada informe y en el futuro, si agrega otra columna o algo, debe cambiar en cada informe, suponiendo que cada informe tenga su propio conjunto de datos.

Me gustaría elogiossi mi solución ayudara.👉Si puedes pasar tiempo publicando la pregunta, también puedes hacer esfuerzos para dar a Kudos quien haya ayudado a resolver tu problema. ¡Es una muestra de agradecimiento!

Visítenos enhttps://perytus.com, su ventanilla única para proyectos/formación/consulta relacionados con Power BI.






Did I answer your question? Mark my post as a solution.

Proud to be a Super User! Appreciate your Kudos 🙂
Feel free to email me with any of your BI needs.





Helpful resources

Announcements
PBI_User Group Leader_768x460.jpg

Manage your user group events

Check out the News & Announcements to learn more.

Welcome Super Users.jpg

Super User Season 2

Congratulations, the new Super User Season 2 for 2021 has started!

Community Connections 768x460.jpg

Community & How To Videos

Check out the new Power Platform Community Connections gallery!

Teds Dev Camp Oct. 2021 768x460.jpg

Power BI Dev Camp - October 28th, 2021

Mark your calendars and join us for our next Power BI Dev Camp!

Top Solution Authors