¿Cuáles son los beneficios de utilizar la sintaxis de Row Constructor en una instrucción de inserción T-Sql?

Question

En SQL Server 2008, puede utilizar la sintaxis Fila Constructor para insertar varias filas con una sola instrucción de inserción, por ejemplo:

insert into MyTable (Col1, Col2) values 
    ('c1v', 0), 
    ('c2v', 1), 
    ('c3v', 2); 

¿Hay beneficios de hacer esto en lugar de tener declaración de una pieza de inserción para cada registro que no sea ¿legibilidad?

Gracias.

Answer 1

Rendimiento no. Es menos código para escribir y más fácil de leer (en mi opinión).

Answer 2

Si va a insertar más de una columna de datos con un SELECT, además de sus filas el tipo explícito, la tabla de valores Constructor será necesario que para explicar en detalle cada columna individual en contraposición a cuando se utiliza una INSERT declaración, puede especificar varias columnas en el SELECT.

Por ejemplo:

USE AdventureWorks2008R2; 
GO 
CREATE TABLE dbo.MyProducts (Name varchar(50), ListPrice money); 
GO 
-- This statement fails because the third values list contains multiple columns in the subquery. 
INSERT INTO dbo.MyProducts (Name, ListPrice) 
VALUES ('Helmet', 25.50), 
     ('Wheel', 30.00), 
     (SELECT Name, ListPrice FROM Production.Product WHERE ProductID = 720); 
GO 

fallaría; que tendría que hacerlo de esta manera:

INSERT INTO dbo.MyProducts (Name, ListPrice) 
VALUES ('Helmet', 25.50), 
     ('Wheel', 30.00), 
     ((SELECT Name FROM Production.Product WHERE ProductID = 720), 
     (SELECT ListPrice FROM Production.Product WHERE ProductID = 720)); 
GO 

ver Table Value Constructor Limitations and Restrictions

Answer 3

No hay ninguna ventaja de rendimiento como se ha mencionado Abe.

El orden del constructor de columnas es el orden requerido para los valores (o instrucción de selección). Puede enumerar las columnas en cualquier orden; los valores deberán seguir ese orden.

Si accidentalmente cambia columnas en la instrucción de selección (o cláusula de valores) y los tipos de datos son compatibles, usar la construcción de columnas le ayudará a encontrar el problema.

Answer 4

Las respuestas a esta pregunta hasta ahora han sido extremadamente engañosa (y demostrar una completa falta de esfuerzo/comprensión) ya que hay una diferencia bastante grande rendimiento entre:

declare @numbers table (n int not null primary key clustered); 

insert into @numbers (n) 
values (0) 
    , (1) 
    , (2) 
    , (3) 
    , (4); 

y

declare @numbers table (n int not null primary key clustered); 

insert into @numbers (n) values (0); 
insert into @numbers (n) values (1); 
insert into @numbers (n) values (2); 
insert into @numbers (n) values (3); 
insert into @numbers (n) values (4); 

El hecho de que cada declaración insert tiene su propia transacción implícita garantiza esto. Puede probarlo fácilmente viendo los planes de ejecución para cada declaración o cronometrando las ejecuciones usando set statistics time on;. Hay un costo fijo asociado con "configurar" y "derribar" el contexto para cada inserción individual y la segunda consulta tiene que pagar esta penalización cinco veces, mientras que la primera solo paga una vez.

No sólo es el método de la lista más eficiente pero también se puede utilizar para construir una tabla derivada:

select * 
from (values 
    (0) 
    , (1) 
    , (2) 
    , (3) 
    , (4) 
) as Numbers (n); 

Este formato se pone alrededor de la limitación 1.000 de valor y le permite unirse y filtrar la lista antes de que se está insertado. ¡Uno también podría notar que no estamos obligados a la declaración insert en absoluto! Como una tabla de facto, esta construcción se puede usar en cualquier lugar donde una referencia de tabla sea válida.