Azure-Sql-Db

SQL Interview: 81 COUNT(*) and COUNT(Column)

SQL Interview: 81 COUNT(*) and COUNT(Column)

This is a post in the SQL Interview series. These aren’t trick or gotcha questions, they’re just questions designed to scope out a candidate’s knowledge around SQL Server and Azure SQL Database.

Section: Development Level: Medium

Question:

You execute the following code:

DROP TABLE IF EXISTS dbo.Table1;
GO

CREATE TABLE dbo.Table1
(
    Column1 int NULL
);
GO

INSERT dbo.Table1 (Column1)
VALUES (1), (NULL), (NULL), (2);
GO

-- Query 1
SELECT COUNT(*), COUNT(Column1)
FROM dbo.Table1;

-- Query 2
SELECT COUNT(*), COUNT(Column1)
FROM dbo.Table1
WHERE Column1 = NULL;

What values will be returned for each query?

2025-09-25

Data Tales 6: The case of the database diet (Part 1)

Data Tales 6: The case of the database diet (Part 1)

This is the sixth tale in a series of stories about data. I hope you enjoy the series.

Time for a diet

One of the busiest places to be in the new year is in any gym. So many people make new year resolutions and in so many cases, it involves losing weight. So I thought I’d start the new year with a tale of a database that needed to go on a diet. The client’s primary database started at 3.8 TB. This case will be described over a short series of articles. This is part 1 and describes phase 1 of the diet.

2025-09-23

SQL Interview: 80 Automatic roll back of transactions

SQL Interview: 80 Automatic roll back of transactions

This is a post in the SQL Interview series. These aren’t trick or gotcha questions, they’re just questions designed to scope out a candidate’s knowledge around SQL Server and Azure SQL Database.

Section: Development Level: Medium

Question:

You are reviewing T-SQL transactional code that does not appear to be working as expected. The following code is being executed:

BEGIN TRAN;

UPDATE Table1 SET Column1 = 12 WHERE Column2 = 14;
UPDATE Table2 SET Column3 = 15 WHERE Column4 = 99;

COMMIT TRAN;

The second update (for Table2) is failing with a foreign key violation, but the update to Table1 is not being rolled back.

2025-09-21

Data Tales 5: The case of the rogue index

Data Tales 5: The case of the rogue index

This is the fifth tale in a series of stories about data. I hope you enjoy the series.

3rd party applications and indexes

Most of my end-user clients run applications that are written by other companies ie: 3rd party applications. Very few write most of their own applications. One of the endless challenges with this is that the application vendors never want their clients to make any changes to the databases that are used by their applications. As a customer, it can be very painful to see performance problems caused by poor or inappropriate indexing choices, and yet to be blocked out from fixing those issues by supportability concerns.

2025-09-19

SQL Interview: 79 Extensive use of varchar(max)

SQL Interview: 79 Extensive use of varchar(max)

This is a post in the SQL Interview series. These aren’t trick or gotcha questions, they’re just questions designed to scope out a candidate’s knowledge around SQL Server and Azure SQL Database.

Section: Administration Level: Advanced

Question:

You are reviewing a database design from one of your developers.

He normally works with PostgreSQL and in that language, he uses the text data type for all strings.

When creating the database in SQL Server, he has used the varchar(max) data type for all strings.

2025-09-17

Data Tales 4: The case of the phantom duplicates

Data Tales 4: The case of the phantom duplicates

This is the fourth tale in a series of stories about data. I hope you enjoy the series.

As very few people seem to have worked with SQLCMD mode, I thought I’d start this article with a little background.

Some background

Way back in SQL Server 2005, Microsoft added SQLCMD as a new command line tool to replace OSQL. It was an OLE-DB based tool rather than an ODBC based tool and had a richer set of options. For example, you could execute operating system commands within your scripts.

2025-09-15

SQL Interview: 78 SELECT *

SQL Interview: 78 SELECT *

This is a post in the SQL Interview series. These aren’t trick or gotcha questions, they’re just questions designed to scope out a candidate’s knowledge around SQL Server and Azure SQL Database.

Section: Development Level: Medium

Question:

You use a tool that does static code analysis of your T-SQL code.

It identifies the following predicate as an issue:

WHERE EXISTS 
(
    SELECT * 
    FROM dbo.Products AS p 
    WHERE p.ProductID = c.ProductID
)

Is this an issue?

2025-09-13

SQL Interview: 77 SARGability

SQL Interview: 77 SARGability

This is a post in the SQL Interview series. These aren’t trick or gotcha questions, they’re just questions designed to scope out a candidate’s knowledge around SQL Server and Azure SQL Database.

Section: Development Level: Medium

Question:

A DBA at your site tells you that you need to make sure your predicates are sargable.

What is SARGability?

Assume a table has a column called OrderDate and it is of date data type. There is a single column index on the column. Can you give an example of a non-sargable predicate that uses it?

2025-09-09

SQL Interview: 76 Performance of temporary tables vs table variables

SQL Interview: 76 Performance of temporary tables vs table variables

This is a post in the SQL Interview series. These aren’t trick or gotcha questions, they’re just questions designed to scope out a candidate’s knowledge around SQL Server and Azure SQL Database.

Section: Administration Level: Medium

Question:

Are there situations where temporary tables will perform better than table variables?

What could cause that?

Answer:

Temporary tables have two properties that are not available to table variables:

  • Indexes - with table variables, you can have primary key constraints and unique key constraints, but not other indexes
  • Statistics - temporary tables support rich statistics, similar to tables where table variables have very limited statistics, mostly just cardinality.

2025-09-05

Data Tales 2: The case of the exploding table

Data Tales 2: The case of the exploding table

This is the second tale in a series of stories about data. I hope you enjoy the series.

I was recently at a customer site where the developers were very concerned about the impact of adding columns to a table. They told me that when they added a new column that their deployment code was timing out and the database was massively increasing in size.

The table had increased from around a small size to well over 50GB during the single operation. The deployment operation involved adding the column and writing one row to a deployment history table. Because they were only writing a single new row, they were blaming SQL Server for bloating the database size when a column was added.

2025-09-03