In data warehousing and analytics databases, a fact table is where you store the actual measurements and metrics of your business. It’s the table that contains the numbers you want to analyze. This could include things like sales amounts, quantities, counts, durations, or any other quantifiable data points.
Fact tables are the foundation of dimensional modeling, the approach most commonly used for organizing data in data warehouses and business intelligence systems.
Query Store captures query execution history, plans, and runtime statistics over time. If you need to stop this data collection (whether to reduce overhead, troubleshoot issues, or prepare for maintenance) you can disable Query Store on a per-database basis.
Survey data can be messy. You’ve got responses scattered across dozens or hundreds of rows, multiple choice answers, rating scales, and so on. And the challenge of turning all that raw data into something stakeholders can actually understand. A well-designed survey dashboard can transform those individual responses into a grid that shows patterns instantly. For example, which questions are getting strong agreement, where opinions diverge, and what trends emerge across different respondent groups.
One of DATEADD()‘s less obvious features in SQL Server is its ability to accept expressions as the interval parameter rather than just simple numeric values. You can perform calculations, use arithmetic operations, or reference multiple columns right inside the function call. This gives you a more flexible way to calculate dates when the offset itself needs to be computed based on your data.
So, instead of adding or subtracting a fixed number of days, months, or years, you compute that number on the fly using whatever logic makes sense for your situation. Let’s look at an example that demonstrates this concept.
If you’ve ever worked with data warehouses or business intelligence systems, you’ve probably encountered star schemas. Perhaps even without realizing it. Star schemas are one of the most common ways to organize data for analytics and reporting.
Star schemas look exactly like their name suggests. They consist of a central table surrounded by related tables, forming a star shape.
Star schemas are designed specifically for querying and analysis rather than transactional operations. They make it easy to slice and dice data in ways that business users actually care about.
If you’ve spent any time working with relational databases, you’re probably well aware of the concept of normalization. This is the process of organizing data in a way that reduces redundancy and maintains consistency. It’s basically SQL Database Design 101. And for good reason.
But sometimes the “right” way to design a database isn’t necessarily the most practical way to run it. Sometimes we need to tweak the thing until we get it performing just right. And sometimes this means deviating from the norm and using a different approach. Denormalization is an example of this.
A query plan cache is an area of a database management system‘s memory that stores compiled execution plans for queries. When you execute a query, the database’s optimizer analyzes the query and creates an execution plan, which is basically a set of instructions for how to retrieve and process the requested data.
But compiling this plan requires computational resources, so database systems cache it in memory for reuse rather than recompiling the same plan repeatedly.
This caching mechanism is a fundamental performance optimization found in virtually all modern relational database systems. By reusing compiled plans, databases avoid the overhead of repeatedly analyzing the same queries, resulting in faster query execution and reduced CPU consumption.
SQL Server’s Query Store can capture wait statistics that show what queries are waiting on during execution. This includes things like locks, I/O, CPU, memory, and other resources. This can help you understand not just that a query is slow, but why it’s slow. Wait statistics are available in SQL Server 2017 and later.
SQL Server’s window functions allow you to perform calculations across sets of rows that are related to the current row, without collapsing those rows into a single result like traditional GROUP BY aggregates would. When combined with the DATEDIFF() function, they can open up many options for analyzing temporal patterns in your data.
Moving averages smooth out short-term fluctuations to reveal longer-term trends in your data. Unlike a simple overall average that treats all historical data equally, a moving average focuses on a sliding window of recent events. This can be quite relevant when analyzing process durations, response times, or any time-based metric where you want to understand current performance trends without being overly influenced by distant historical data.
When working with databases, there’s a good chance you’ve had to deal with transactions. Transactions are those “all or nothing” blocks of work that make sure your data stays consistent. But what happens if you’re halfway through a transaction and realize that only part of it needs to be undone, not the whole thing? That’s where savepoints can help.
In SQL, a savepoint is basically a checkpoint you can set inside a transaction. It lets you roll back to that specific point if something goes wrong, without undoing everything that came before it. If something gets messed up, you can load your last save instead of starting again from scratch.