CASE в UPDATE дает неожиданные результаты.Исправлено при перемещении в предложение WHERE.Зачем? - PullRequest
3 голосов
/ 26 марта 2019

Я создал запрос для обновления флага, я использовал оператор CASE, чтобы определить значение. Однако когда я запускаю запрос как оператор UPDATE, обновляется только около половины ожидаемых строк? Еще интереснее то, что ранее я выполнял точно такой же запрос UPDATE для тех же данных, и он работал как ожидалось (то, что заставило меня заняться расследованием старых и новых).

Я попытался выполнить запрос SELECT, используя тот же оператор CASE, я получил правильные результаты, но переключение обратно на UPDATE обновляет только примерно половину записей.

Перемещение критериев в предложение WHERE устранило проблему. Похоже, что оператор CASE в части SET вызывает проблемы. Я не могу понять, почему? Я хотел бы знать, чтобы избежать любой ошибки, которую я сделал в будущем.

Оригинальный код:

UPDATE D
SET PUBLISH_FLAG =
CASE WHEN
         MAPPED_CAT NOT IN(1,2,3)
    AND SRC != '999'
    AND RECEIVED_DATE is not null
    AND RECEIVED_DATE <= D.CENSUS_DATE
    AND SCHEDULED_FLAG = 'N'
    THEN 'Y'
    ELSE 'N'
END
FROM TBL_DATA D
INNER JOIN TBL_PUBLISH V
    ON D.ID = V.ID
    AND D.CENSUS_DATE = V.CENSUS_DATE
    AND D.VERSION_NUMBER = V.VERSION_NUMBER
LEFT JOIN TBL_CAT_MAP C
       ON D.SRC_CATEGORY = C.SOURCE_CAT 

Рабочий код:

UPDATE D
SET PUBLISH_FLAG = 'Y'
FROM TBL_DATA D
INNER JOIN TBL_PUBLISH V
    ON D.ID = V.ID
    AND D.CENSUS_DATE = V.CENSUS_DATE
    AND D.VERSION_NUMBER = V.VERSION_NUMBER
LEFT JOIN TBL_CAT_MAP C
    ON D.SRC_CATEGORY = C.SOURCE_CAT 
WHERE
         MAPPED_CAT NOT IN(1,2,3)
    AND SRC != '999'
    AND RECEIVED_DATE is not null
    AND RECEIVED_DATE <= D.CENSUS_DATE
    AND SCHEDULED_FLAG = 'N'

Я думал, что оба должны давать одинаковые результаты? Чего мне не хватает?

Чтобы пояснить, что в приведенном ниже коде 2 показывает разницу, столбец «PUBLISH_FLAG» (обновленный с использованием моего исходного кода или ответа PSK) имеет 10162 значений «Y» (остальные «N»), столбец pub_2 имеет правильные 18917 'Y' значения.

SELECT
PUBLISH_FLAG,
CASE WHEN
         MAPPED_CAT NOT IN(1,2,3)
    AND SRC != '999'
    AND RECEIVED_DATE is not null
    AND RECEIVED_DATE <= D.CENSUS_DATE
    AND SCHEDULED_FLAG = 'N'
    THEN 'Y'
    ELSE 'N'
END as pub_2
FROM TBL_DATA D
INNER JOIN TBL_PUBLISH V
    ON D.ID = V.ID
    AND D.CENSUS_DATE = V.CENSUS_DATE
    AND D.VERSION_NUMBER = V.VERSION_NUMBER
LEFT JOIN TBL_CAT_MAP C
    ON D.SRC_CATEGORY = C.SOURCE_CAT 
WHERE
CASE WHEN
         MAPPED_CAT NOT IN(1,2,3)
    AND SRC != '999'
    AND RECEIVED_DATE is not null
    AND RECEIVED_DATE <= D.CENSUS_DATE
    AND SCHEDULED_FLAG = 'N'
    THEN 'Y'
    ELSE 'N'
END = 'Y'

Ответы [ 3 ]

1 голос
/ 26 марта 2019

Ваш первый запрос определенно не совпадает с вашим вторым.Фактически из того, что я вижу здесь, я бы сказал, что ваше обновление с CASE является правильным, поскольку оно обновляет обе стороны флага.Другой запрос с WHERE не обновляет флаг до N, где он должен.Как именно вы определяете «правильное» количество ожидаемых обновлений?Я думаю, вы ожидаете, что ваш оператор UPDATE будет иметь столько же строк, сколько и оператор SELECT, хотя это не всегда так.Соединение, которое вы делаете, может производить декартово произведение в зависимости от ваших фильтров.

Рассмотрите запрос ниже.

CREATE TABLE #table1 (Field_1 INT, Field_2 VARCHAR(MAX))
INSERT INTO
    #table1
VALUES
    (1, 'Item A'),
    (2, 'Item B'),
    (3, 'Item C'),
    (4, 'Item D'),
    (5, 'Item E')

CREATE TABLE #table2 (Field_1 INT, Field_2 VARCHAR(MAX))
INSERT INTO
    #table2
VALUES
    (1, 'Item A'),
    (1, 'Item B'),
    (2, 'Item B'),
    (2, 'Item C'),
    (3, NULL)

-- This produces 7 rows:
SELECT
    *
FROM
    #table1
LEFT JOIN
    #table2 ON #table1.[Field_1] = #table2.[Field_1]

-- This updates 1 row. This is akin to your second query. Only one flag value is changed.
-- You would still have to write an UPDATE statement for the 'N' flag update.
UPDATE
    #table1
SET
    #table1.[Field_2] = 'Y'
FROM
    #table1
LEFT JOIN
    #table2 ON #table1.[Field_1] = #table2.[Field_1]
WHERE
     #table2.[Field_2] = 'Item C'

-- Because your UPDATE statement only updates the values to 'Y' where a condition matches, only one record is changed here.
-- The others are left untouched.
SELECT
    *
FROM
    #table1

-- Now what happens if we perform the reverse UPDATE.
UPDATE
    #table1
SET
    #table1.[Field_2] = 'N'
FROM
    #table1
LEFT JOIN
    #table2 ON #table1.[Field_1] = #table2.[Field_1]
WHERE
     NOT (#table2.[Field_2] = 'Item C')

-- First of all we notice that we are not dealing with NULL values at all so only two records get changed to 'N'.
-- The first record gets changed because it does not have a match on 'Item C'.
-- The second record also gets changed because it does not have a match on 'Item C', i.e. there is at least one record without an 'Item C' match.
-- The last three records have either no match in the JOIN or are NULL in #table2. Meaning they are not updated.
-- This is why I'm more a fan of your CASE query, because in theory it should deal with setting everything to the correct value.
SELECT
    *
FROM
    #table1

-- Let's see what would happen with a CASE statement.
-- Since our JOIN is a cartesian product there are multiple options for #table1.Id == 2: it can be updated to both N and Y.
-- N is chosen by T-SQL. You will see that after the UPDATE.
SELECT
    *, CASE WHEN #table2.[Field_2] = 'Item C' THEN 'Y' ELSE 'N' END
FROm
    #table1
LEFT JOIN
    #table2 ON #table1.[Field_1] = #table2.[Field_1]

-- This updates 5 rows, maybe you would have expected 7 here based on the above SELECT statement?
-- You can also notice how it updates everything to N, that's because our CASE deals with both sides.
-- It's either 'Y' or either 'N'. It will always touch every record it can to UPDATE it.
-- This in contrast with an UPDATE statement which will only touch one side and because of JOIN clauses and NULL values
-- it's entirely possible that both UPDATE statements do not touch the entire table if written incorrectly.

-- You would have to write an UPDATE statement like this one, which comes after the first.
--UPDATE
--    #table1
--SET
--    #table1.[Field_2] = 'N'
--FROM
--    #table1
--LEFT JOIN
--    #table2 ON #table1.[Field_1] = #table2.[Field_1]
--WHERE
--     #table1.[Field_2] <> 'Y' OR #table1.[Field_2] IS NULL

-- In conclusion this means that if you want to be absolutely sure you have updated all values to their correct setting: use CASE.
-- But if you only care about setting 'Y' to the correct value: don't use CASE.
-- If you do use CASE, make sure you are definitely performing your JOIN correct and you are calculating the correct value for both sides.
UPDATE
    #table1
SET
    #table1.[Field_2] = CASE WHEN #table2.[Field_2] = 'Item C' THEN 'Y' ELSE 'N' END
FROM
    #table1
LEFT JOIN
    #table2 ON #table1.[Field_1] = #table2.[Field_1]

SELECT
    *
FROM
    #table1

DROP TABLE #table1
DROP TABLE #table2
1 голос
/ 26 марта 2019

Оба запроса не совпадают, в первом запросе все несопоставленные записи в случае переключения будут установлены как 'N', независимо от их текущего состояния.

Второй запрос - этоправильный подход для сценария такого типа, когда вы обновляете только необходимые записи.

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

UPDATE D
SET PUBLISH_FLAG =
CASE WHEN
         MAPPED_CAT NOT IN(1,2,3)
    AND SRC != '999'
    AND RECEIVED_DATE is not null
    AND RECEIVED_DATE <= D.CENSUS_DATE
    AND SCHEDULED_FLAG = 'N'
    THEN 'Y'
    ELSE PUBLISH_FLAG --Modified
END
FROM TBL_DATA D
INNER JOIN TBL_PUBLISH V
    ON D.ID = V.ID
    AND D.CENSUS_DATE = V.CENSUS_DATE
    AND D.VERSION_NUMBER = V.VERSION_NUMBER
LEFT JOIN TBL_CAT_MAP C
       ON D.SRC_CATEGORY = C.SOURCE_CAT 

Примечание: В приведенном выше запросе я изменил остальную часть.

0 голосов
/ 26 марта 2019

это зависит от условий вашего флага, которые вы сделали.

в соответствии с вашим левым соединением будет выполнено объединение по количеству записей, но когда вы применяете условия «Где», тогда записи будут отфильтровываться, но вы применяете регистр, тогда количество записей остается таким же, как и ранее, но в соответствии с флагом соответствия условия только обновит не все. Так что это обновление на половине записей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...