DirectQuery transforms the Microsoft SQL Server Analysis Services Tabular model into a metadata layer on top of an external database. For SQL Server 2016, DirectQuery was redesigned for dramatically improved speed and performance, however, it is also now more complex to understand and implement. There are many tradeoffs to consider when deciding when to use DirectQuery versus in-memory mode (VertiPaq). Consider using DirectQuery if you have either a small database that is updated frequently or a large database that would not fit in memory.
Table of Contents
- Introduction to Tabular processing
- Pros and cons
- Example comparing a model designed for in-memory versus DirectQuery
- Introduction to DirectQuery
- Calculated tables and columns
- DAX
- MDX
- Understanding DirectQuery
- Introducing the DirectQuery architecture
- Using supported data sources
- Building models for DirectQuery
- Understanding query limits
- Using DAX in DirectQuery
- Using MDX in DirectQuery
- Using row-level security
- Using DirectQuery, real-time, and different client tools
- Do you need real-time systems?
- Creating a DirectQuery model
- Creating sample data for DirectQuery
- Setting DirectQuery mode after deployment
- Security setting in DirectQuery
- Optimizing DirectQuery
- Understanding datatype handling in DirectQuery
- Simple query on a star schema and on snowflake schemas
- Filter over a calculated column
- Using time intelligence functions with additive measures
- Using time intelligence functions with non-additive measures
- Using time intelligence functions with semi-additive measures
- Many-to-many relationships
- Comparing DirectQuery with in-memory mode (VertiPaq)
- Conclusion
- Appendix: Semantic differences in DAX
- Comparisons
- Casts
- Math functions and arithmetic operations
- Aggregation functions
- Text functions