Проверки NULL AdventureWorks в SQL Server 2016 - PullRequest
Новая
       13

Проверки NULL AdventureWorks в SQL Server 2016

2 голосов
/ 12 апреля 2019

Я работаю над двумя различными заданиями, в которых я должен выполнять нулевые проверки, но я не уверен, правильно ли я написал синтаксис для этого, мой инструктор на самом деле не обсуждал это, но будет отмечать его.

Ниже приведены 2 вопроса и то, что я написал. Любая помощь приветствуется.

Задание 1 вопрос: Создайте список номеров заказов на продажу для заказов, не заказанных онлайн и не с помощью кредитной карты. Примечание: 0 - ложь, а 1 - битовые поля. Ниже приведен синтаксис, который я использовал, я делаю здесь проверку на ноль? 

SELECT SalesOrderNumber
FROM Sales.SalesOrder_json
WHERE OnlineOrderFlag = 0 AND CreditCardID IS NULL

Вопрос по заданию 2: список поставщиков, у которых нет товаров. Ниже приведен синтаксис, который я использовал, я делаю здесь проверку на ноль? 

SELECT 
    pv.Name AS Vendors, 
    COUNT(PP.ProductID) AS 'Products'
FROM 
    Purchasing.Vendor AS PV
LEFT JOIN 
    Purchasing.ProductVendor AS PPV ON PV.BusinessEntityID = PPV.BusinessEntityID
LEFT JOIN 
    Production.Product AS PP ON PP.ProductID = PPV.ProductID 
GROUP BY 
    PV.Name
HAVING 
    COUNT(PP.ProductID)  = 0;

1 Ответ

1 голос
/ 12 апреля 2019

Добро пожаловать в переполнение стека!
В будущем, пожалуйста, опубликуйте сводку или создайте операторы таблиц, которые представляют схему таблиц, используемых в ваших запросах, чтобы у нас было достаточно информации, чтобы предоставить больше, чем просто умозрительные ответы. Несмотря на то, что это база данных Adventure Works, вы должны начать свое путешествие с хорошими привычками!

пожалуйста, постарайтесь не публиковать прямые вопросы о заданиях в Интернете, поскольку большинство проверяющих академических заданий вы легко справитесь с плагиатом, главным образом потому, что другие студенты могут видеть ваш пост и поддержку, которую вы получаете от сообщества, что может привести ко всем Вы даете тот же результат.

Запускали ли вы свои запросы? Как вы думаете, результаты верны?

Если результаты ваших запросов верны, то единственной проблемой является "Вы делали какие-либо нулевые проверки" ? Можно сказать, что если ваши результаты дали правильные результаты, значит, вы удовлетворяли критериям, в противном случае вопрос был сформулирован не очень хорошо.

Нулевые проверки можно объединить в 3 шаблона:

  1. Вы напрямую сравниваете с нулем, используя IS NULL или IS NOT NULL в своем запросе

  2. Использование синтаксиса JOIN для работы с данными, которые могут иметь значения NULL.

    • INNER JOIN ограничит результаты только записями, которые совпадают в обеих таблицах. Используйте это, если вам нужно пропустить записи, которые имеют null в поле внешнего ключа.
    • Non INNER присоединяется, как LEFT JOIN. Это вернет результаты из левой таблицы, даже если в объединенной или правой таблице нет совпадающих записей.

  3. При использовании функций агрегации агрегаты обычно пропускают нулевые значения, COUNT будет возвращать 0, если все значения равны NULL, где в качестве других агрегатов, таких как SUM, MIN, MAX, AVG вернет NULL, если все значения NULL

Вопрос 1
Очевидно, вы внедрили проверку NULL, потому что вы оценивали критерии непосредственно в столбце, допускающем значение NULL.

Похоже, ваш ответ на вопрос 1 довольно хороший.

Вопрос 2 Хотя ваш запрос выглядит так, как будто он возвращает поставщиков без продуктов, он также возвращает нулевое значение.

Вам не нужно выводить столбец, чтобы можно было использовать его в критериях фильтра, поэтому удалите COUNT(PP.ProductID) AS 'Products', если только вы не получили инструкций по его использованию.

Это проверка NULL ... Что до интерпретации, я думаю, что в этом случае ответ - да. Используя LEFT JOIN (или соединения OUTER), вы создали набор результатов, который будет иметь поле PP.ProductID со значением NULL, если продуктов нет.

Использование Count в критериях фильтрации для этого нулевого столбца и признание того, что Count с нулевым результатом означает, что столбец ProductID был фактически нулевым, означает, что вы оценили нулевую проверку.

Существуют и другие способы запроса тех же результатов, например, использование NOT EXISTS. NOT EXISTS NOT будет прямой нулевой проверкой, потому что NULLABILITY не была оценена напрямую.

...