W odpowiedzi na pytanie dotyczące dziwnych wartości w PERSISTED
kolumnie obliczeniowej. Odpowiedź zawiera kilka domysłów na temat tego, jak powstało to zachowanie.
Pytam: czy to nie jest zwykły błąd? Czy PERSISTED
kolumny mogą kiedykolwiek zachowywać się w ten sposób?
DECLARE @test TABLE (
Col1 INT,
Contains2 AS CASE WHEN 2 IN (Col1) THEN 1 ELSE 0 END PERSISTED) --depends on Col1
INSERT INTO @test (Col1) VALUES
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5))
SELECT * FROM @test --shows impossible data
UPDATE @test SET Col1 = Col1*1 --"fix" the data by rewriting it
SELECT * FROM @test --observe fixed data
/*
Col1 Contains2
2 0
2 0
0 1
4 0
3 0
Col1 Contains2
2 1
2 1
0 0
4 0
3 0
*/
Zauważ, że dane wydają się „niemożliwe”, ponieważ wartości wyliczonej kolumny nie odpowiadają jej definicji.
Dobrze wiadomo, że funkcje niedeterministyczne w zapytaniach mogą zachowywać się dziwnie, ale tutaj wydaje się to naruszać umowę utrwalonych kolumn obliczeniowych, a zatem powinno być nielegalne.
Wstawianie liczb losowych może być wymyślonym scenariuszem, ale co, jeśli wstawimy NEWID()
wartości lub SYSUTCDATETIME()
? Myślę, że jest to istotny problem, który może się praktycznie objawić.