In database terminology, an attribute is a piece of information that describes an entity. If an entity is a thing you want to store data about, attributes are the specific details you’re storing. They’re the characteristics, properties, or facts that define what you know about each entity.
When you create a relational database, attributes become the columns in your tables. Each attribute represents one type of information you’re tracking.
In database design, an entity is something you want to store information about. It’s a person, place, thing, event, or concept that matters to your application and has data associated with it that you need to track.
Entities are the building blocks of database design. Before you create tables, write queries, or think about indexes, you need to identify what entities exist in your domain and what information you need to store about them.
When you have Query Store enabled in SQL Server, it consumes disk space in order to store query text, execution plans, and runtime statistics. Monitoring storage usage can help you avoid situations where Query Store fills up and stops capturing data or switches to read-only mode.
In SQL Server, Query Store aggregates performance statistics into time intervals, allowing you to see how query performance changes over time. This historical view helps you identify when performance degraded, spot patterns like daily or hourly spikes, and correlate performance changes with deployments or data changes.
This assumes that Query Store is enabled on the database in question. So assuming Query Store is enabled on the database, you can use the following queries to check the execution history of queries over time.
SQL Server has a concept of “missing indexes”. And no, it’s not referring to an index that used to be there but has now disappeared. Rather, the missing index concept is designed to help us improve the performance of our database.
A missing index is an index that doesn’t yet exist on your table but probably should. SQL Server actually tracks queries that would benefit from indexes and stores suggestions in a set of dynamic management views (DMVs) called the missing index DMVs.
When you run a query and the optimizer thinks that this would be way faster with an index on those columns, it logs that suggestion. Over time, these suggestions accumulate, giving you a prioritized list of indexes that could improve your database’s performance.
Running a full-featured Microsoft SQL Server on a Mac used to be a headache, but as of 2026, it is smoother than ever. Thanks to improvements in Docker Desktop and macOS’s Rosetta 2 translation, you can now run the enterprise-grade engine (including the new SQL Server 2025 Preview) directly on your M1, M2, M3, or M4 Mac.
This guide will walk you through setting up a modern SQL Server environment from scratch.
SQL Server’s Query Store captures all executed queries (or a subset based on your capture mode) along with their execution statistics. Viewing the complete list of captured queries helps you understand what’s been tracked and provides a starting point for performance analysis.
In data warehousing, a slowly changing dimension (SCD) is a dimension table where the attributes change over time, but not very frequently. The term “slowly changing” refers to the fact that these changes happen occasionally (perhaps days, weeks, or months apart) rather than constantly like transactional data.
The challenge is figuring out how to handle these changes while maintaining accurate historical analysis. When a customer moves to a new state or a product gets recategorized, you need a strategy that preserves the integrity of your historical data.
Polyglot persistence is an architectural approach where an application uses multiple different database technologies, each chosen for its specific strengths and matched to particular data storage needs. Instead of forcing all your data into one database system, you use the right database for each job. For example, a relational database for transactional data, a document store for flexible content, a cache for session data, and a graph database for relationships.
When you’re analyzing how events unfold over time in a SQL database, one of the biggest challenges can be efficiently comparing what’s happening now to what comes next. Each event typically appears as its own row with a timestamp, but meaningful insight often comes from understanding how those timestamps relate to one another. Fortunately SQL Server provides some useful tools for this kind of sequential analysis.
Rather than relying on bulky self-joins or multi-step logic, SQL window functions offer a streamlined way to track these transitions. For example, by pairing the LEAD() function with DATEDIFF(), you can instantly measure the gap between consecutive events and surface insights that would otherwise require far more complex queries.