Both a source table and a view can be considered. A view can be beneficial if we want aggregation to happen at the source.
However, I would prefer not to tightly couple the Qlik application logic with the source view. Dashboard requirements can evolve, and changes to dimensions, measures, filters, or aggregation logic may require corresponding changes in the data extraction.
A better approach would be to extract the required granular data from the source system, persist it in QVD format, and use the QVDs as the reusable data layer for Qlik applications. This separates source extraction from application-specific transformation logic, provides greater flexibility for future dashboard changes, and reduces the need to repeatedly query the source system.
Hi, if the data will be analyzed only in Qlik I would prefer to extract the tables and create the logic in Qlik.
Views can also be used, but in that case the maintenance goes to the department that manages the views, this is usually used:
- By teams that are not used to do the ETL using Qlik script language and methodology, so they use their SQL or query language they know to create the tables.
- When the data might be used by different tools, so it's calculated in one source and every tool reads from it.
One way or another, for Qlik it will be better to user a qvd layer and use incremental loads when possible.
