Hemos estado indagado por todo el mundo on line para brindarte la respuesta para tu duda, en caso de dudas puedes dejarnos tu pregunta y te contestaremos sin falta, porque estamos para servirte.
Solución:
los subquery que tienes en tu código se llama tabla derivada. No es una tabla base sino una tabla que “vive” durante el tiempo que se ejecuta la consulta. Me gusta puntos de vista (que también se llaman tablas vistas) – y en versiones recientes CTE que es otra cuarta forma de “definir” una tabla dentro de una consulta: son similares a una tabla en muchos aspectos. Puedes select de ellos, puedes usarlos en from o para join a otras tablas (¡base o no!).
En algunos DBMS (no todos los DBMS han implementado esto de la misma manera) estas tablas/vistas son actualizable. Y “actualizable” significa que también podemos update, insert en o delete de ellos.
Sin embargo, hay restricciones y esto se espera. Imagínese si el subquery era una combinación de 2 (o 17 tablas). que seria delete significa entonces? (¿De qué tablas se deben eliminar las filas?) Las vistas actualizables son un asunto muy complicado.. Hay un libro reciente (2012), enteramente sobre este tema, escrito por Chris Date, conocido experto en teoría relacional: View Updating and Relational Theory.
Cuando la tabla (o vista) derivada es una consulta muy simple, como si tuviera solo una tabla base (posiblemente restringida por un WHERE) y no GROUP BYentonces cada fila de la tabla derivada corresponde a una fila en la tabla base subyacente, por lo que es fácil* para actualizar, insertar o eliminar de este.
Cuando el código dentro de la subconsulta es más complejo, depende de si las filas de la tabla/vista derivada se pueden rastrear/resolver en filas de una de las tablas base subyacentes.
Para SQL Server, puede leer más en el párrafo Vistas actualizables en MSDN: CREATE VIEW.
Vistas actualizables
Puede modificar los datos de una tabla base subyacente a través de una vista, siempre que se cumplan las siguientes condiciones true:
Cualquier modificación, incluyendo
UPDATE,INSERTyDELETEdeclaraciones, deben hacer referencia a columnas de una sola tabla base.Las columnas que se modifican en la vista deben hacer referencia directamente a los datos subyacentes en las columnas de la tabla. Las columnas no se pueden derivar de ninguna otra manera, como por ejemplo a través de lo siguiente:
Una función agregada:
AVG,COUNT,SUM,MIN,MAX,GROUPING,STDEV,STDEVP,VARyVARP.Un cómputo. La columna no se puede calcular a partir de una expresión que utiliza otras columnas. Columnas que se forman usando los operadores de conjunto
UNION,UNION ALL,CROSSJOIN,EXCEPTyINTERSECT
equivalen a un cálculo y tampoco son actualizables.Las columnas que se modifican no se ven afectadas por
GROUP BY,HAVINGoDISTINCTcláusulas.
TOPno se usa en ninguna parte del select_statement de la vista junto con elWITH CHECK OPTIONcláusula.Las restricciones anteriores se aplican a cualquier subconsulta en el
FROMcláusula de la vista, tal como se aplican a la vista misma. Por lo general, el Motor de base de datos debe poder rastrear sin ambigüedades las modificaciones desde la definición de la vista hasta una tabla base.
Realmente delete es más fácil, menos complejo que update. SQL Server solo necesita el principal keys o alguna otra forma de identificar qué filas de la tabla base se van a eliminar. Para update, existe una restricción adicional (bastante obvia) de que no podemos actualizar una columna calculada. Puede intentar modificar su consulta para hacer una actualización. Actualizando el CreatedDateTime probablemente funcionará bien pero tratando de actualizar el calculado RowNumber columna generará un error. Y insert es aún más complejo, ya que tendríamos que proporcionar valores para todas las columnas de la tabla base que no tienen un DEFAULT restricción.
Es fácil de ver cuando observa el plan de consulta. En su caso, el plan solo contiene un operador adicional de Proyecto de segmento y secuencia para manejar el número de fila. Este tipo de operación solo funciona cuando SQL Server realmente puede resolver la tabla subyacente.
La eliminación de subconsultas y CTE es totalmente compatible y muy eficiente, especialmente para eliminar duplicados. También creo recordar haberlo usado en versiones anteriores de SQL Server.
Más en una antigua entrada de blog mía.