When you’re building or maintaining a relational database, objects rarely live in isolation. Tables support views, views feed reports, procedures call other procedures, and constraints tie data together. These relationships are called dependencies, and they can be hard or soft.
The difference boils down to how strictly the database enforces the relationship.
In programming, the word idempotent describes an operation that produces the same result no matter how many times it is executed. When applied to SQL, idempotence refers to queries or commands that don’t introduce unexpected changes if you run them repeatedly.
The whole idea is that after the first execution, additional executions should leave the database in the same final state. Not just error-free, but stable and predictable. This concept is especially important when writing scripts that may be re-executed, such as database migrations or automated deployments.
If you’ve been working with SQL Server for a while, you’ve probably come across the term “compatibility level” at some point. Maybe you’ve seen it in database properties or heard someone mention it during a migration discussion. But what exactly does it mean, and why should you care?
Newline Delimited JSON (NDJSON) is a specialized data format that provides a simple yet powerful way to handle streaming JSON data. While standard JSON is excellent for representing structured data, NDJSON addresses specific use cases where processing large datasets and streaming data is required.
This article takes a quick look at NDJSON and how it differs from regular JSON.
JavaScript Object Notation, commonly known as JSON, is a lightweight, text-based data interchange format that has become one of the most widely used standards for transmitting data across the internet.
Despite its origins in JavaScript, JSON has evolved into a language-independent format, making it an essential tool for developers working with any programming language or platform.
Julian day is a concept you might occasionally encounter in SQL code or database operations, particularly when working with date and time functions. While it may seem esoteric at first, understanding Julian day can be incredibly useful for handling date calculations, especially in fields like astronomy, data analysis, and historical research.
This article looks at the origins, calculations, and practical applications of Julian day, including examples of converting between Julian day and other date formats in SQL.
The term “serverless database” has gained popularity with the rise of cloud computing and on-demand services, but it has a dual meaning depending on context.
In particular, databases can be “serverless” in either the traditional, client-side manner (e.g., SQLite’s model) or the cloud-native way often associated with managed databases.
This article explores these two approaches to serverless databases—classic serverless and neo-serverless—along with contrasting examples from other database models like client/server architectures.
In relational database management systems (RDBMSs), constraints are nifty tools that we can use to ensure the integrity, accuracy, and reliability of the data stored in our database.
Constraints can enforce rules at the column and table levels, guiding how data can be inserted, updated, or deleted. Whether you’re defining the uniqueness of a value, establishing relationships between tables, or ensuring that critical fields are never left blank, constraints play an important role in the design of relational databases.
Probably the most widely known key type in SQL is the primary key, which is chosen to uniquely identify each row in a table. Perhaps next is the foreign key, which is used to establish a relationship between tables.
But there are more key types than this, and the differences between them can be subtle, but important. Here we’ll look at nine of the various key types in SQL.
Structured Query Language (SQL) is the backbone of relational database management systems (RDBMSs), enabling users to query, manipulate, and define data. One of the most fundamental concepts in SQL, and one that all SQL developers should understand, is the data type.
Whenever we create a column in SQL, we must define its data type. Similarly, when we create a variable, we define its data type.
So, why is the data type so important? Let’s find out.