Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Earn the coveted Fabric Analytics Engineer certification. 100% off your exam for a limited time only!

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.

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.



Subscribe to the @PowerBIHowTo YT channel for an upcoming video on List and Record functions in Power Query!!

Learn Power BI and Fabric - subscribe to our YT channel - Click here: @PowerBIHowTo

If my solution proved useful, I'd be delighted to receive Kudos. When you put effort into asking a question, it's equally thoughtful to acknowledge and give Kudos to the individual who helped you solve the problem. It's a small gesture that shows appreciation and encouragement! ❤


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
April AMA free

Microsoft Fabric AMA Livestream

Join us Tuesday, April 09, 9:00 – 10:00 AM PST for a live, expert-led Q&A session on all things Microsoft Fabric!

March Fabric Community Update

Fabric Community Update - March 2024

Find out what's new and trending in the Fabric Community.

Top Solution Authors