I am not sure the statement "Aggregating over all NULL values results in an error" is accurate. In the example you have given, using a Table Value Constructor (VALUES clause), I believe you are getting the error because the data type can't be established. If selecting from a normal table, aggregates are allowed on all null values:
CREATE TABLE Customers(
CustomerID INT IDENTITY PRIMARY KEY,
FirstName varchar(50) NOT NULL,
LastName varchar(50) NOT NULL,
Age INT NULL
)
INSERT INTO Customers
(FirstName, LastName, Age)
VALUES
('John','Peter',NULL),
('Raj','Mohan',NULL),
('Krishna','Kumar',NULL)
SELECT
MIN(Age) as MinValue
,MAX(Age) as MaxValue
,SUM(Age) as MaxValue
,AVG(Age) as MaxValue
FROM Customers
I think that statement perhaps needs either amending or possibly leaving out (because the scenario you have used, creating a Table Value Constructor with all NULL values) seems to me not to be realistic.
Unlike most other languages, in SQL null values should not be prevented from appearing but embraced like you showed .
I do not know how deep you intended to go into the subject but I was left thinking that you should have also (at least) mentioned joins.
Joins are one of the backbones of SQL, can introduce a lot of null values into query results and are the main source of confusion to a lot of people (at least people I have meet).
Since joins are such an extensive subject and a little more advanced than filtering a single table, maybe write a follow up article and link to this one. Or mention another article from someone else that details joins.
I would agree with you that a good addition to this article might be a section addressing joins. Maybe we can even do a deeper dive into NULL values—targeted at a more advanced audience. Thank you for your feedback, and I'll relay this onto the writer!
Haha that one too! At first we found handling NULLs to be a bit difficult, or at least not immediately clear the best way to do it. That was the genesis of this article.
Last Visit: 31-Dec-99 18:00 Last Update: 27-Mar-23 15:43