Estoy siguiendo esta pregunta sobre valores extraños en una PERSISTED
columna calculada. La respuesta allí hace algunas conjeturas sobre cómo surgió este comportamiento.
Estoy preguntando lo siguiente: ¿No es esto un error absoluto? ¿Se PERSISTED
les permite a las columnas comportarse de esta manera?
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
*/
Tenga en cuenta que los datos parecen "imposibles" porque los valores de la columna calculada no corresponden a su definición.
Es bien sabido que las funciones no deterministas en las consultas pueden comportarse de manera extraña, pero aquí esto parece violar el contrato de las columnas computadas persistentes y, por lo tanto, debería ser ilegal.
Insertar números aleatorios podría ser un escenario artificial, pero ¿qué pasaría si insertáramos NEWID()
valores o SYSUTCDATETIME()
? Creo que este es un tema relevante que prácticamente podría manifestarse.