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.
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.
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.
A CRDT (Conflict-Free Replicated Data Type) is a special type of data structure designed for distributed systems that guarantees multiple replicas of data will eventually converge to the same state without requiring coordination between nodes. Even when different users simultaneously modify the same data in different locations, CRDTs automatically resolve conflicts in a mathematically consistent way that ensures all replicas eventually agree.
The main insight behind CRDTs is that certain operations can be designed to be commutative, meaning the order in which you apply them doesn’t matter. If operation A followed by operation B produces the same result as operation B followed by operation A, you can apply updates in any order and still reach the same final state. This property eliminates the need for complex conflict resolution logic.
Eventual consistency is a consistency model used in distributed databases where data updates don’t immediately propagate to all copies, but given enough time without new updates, all copies will eventually become identical. When you write data to one location in the system, other locations might temporarily see old data, but they’ll all catch up eventually. This usually happens within milliseconds or seconds (although it can be longer during network issues or node failures).
This approach contrasts with strong consistency, where every read is guaranteed to return the most recent write immediately. With eventual consistency, the system prioritizes availability and performance over immediate accuracy. You’re accepting that different parts of your database might temporarily disagree about the current state of the data in exchange for faster operations and better fault tolerance.
If you’ve ever wondered why your database queries sometimes seem to wait around doing nothing, or why two users can’t update the same record at the exact same moment, you’re dealing with locks. In SQL Server, locks are the fundamental mechanism that keeps your data consistent and prevents the chaos that would ensue if everyone could modify everything simultaneously.
A columnstore index is a type of database index that stores data by column rather than by row. Traditional indexes (and tables) store data row-by-row, where all the values for a single record are kept together. Columnstore indexes flip this around, storing all values from a single column together instead.
This might seem like a small difference, but it fundamentally changes how the database reads and processes data. Columnstore indexes are designed for analytical queries that scan large amounts of data, performing aggregations, calculations, and filtering across millions or billions of rows.
Vertical scaling is the practice of increasing the capacity of a single server by adding more resources to it. For example more CPU power, RAM, storage, or faster hardware. Instead of adding more machines to handle increased load, you make your existing machine more powerful.
In database contexts, vertical scaling means upgrading your database server to more powerful hardware so it can handle more queries, store more data, and process transactions faster. It’s the most straightforward way to improve database performance.
Horizontal scaling is the practice of adding more servers or machines to your system to handle increased load, rather than making individual servers more powerful. Instead of upgrading one server with more CPU and RAM, you add additional servers and distribute the work across all of them.