Pregunta Insertar en ... valores (SELECCIONAR ... DE ...)


estoy tratando de INSERT INTO una tabla que usa la entrada de otra tabla. Aunque esto es totalmente factible para muchos motores de bases de datos, siempre me cuesta recordar la sintaxis correcta para el SQL motor del día (MySQL, Oráculo, servidor SQL, Informixy DB2)

¿Hay una sintaxis de bala de plata proveniente de un estándar SQL (por ejemplo, SQL-92) que me permitiría insertar los valores sin preocuparse por la base de datos subyacente?


1093
2017-08-25 12:45


origen


Respuestas:


Tratar:

INSERT INTO table1 ( column1 )
SELECT  col1
FROM    table2  

Esto es estándar ANSI SQL y debería funcionar en cualquier DBMS

Definitivamente funciona para:

  • Oráculo
  • Servidor MS SQL
  • MySQL
  • Postgres
  • SQLite v3
  • Teradata
  • DB2
  • Sybase
  • Vertica
  • HSQLDB
  • H2
  • AWS RedShift
  • SAP HANA

1277
2017-08-25 12:47



@Shadow_x99: Eso debería funcionar bien, y también puede tener varias columnas y otros datos:

INSERT INTO table1 ( column1, column2, someInt, someVarChar )
SELECT  table2.column1, table2.column2, 8, 'some string etc.'
FROM    table2
WHERE   table2.ID = 7;

Editar: Debo mencionar que solo he usado esta sintaxis con Access, SQL 2000/2005 / Express, MySQL y PostgreSQL, por lo que deberían estar cubiertos. Un comentarista ha señalado que funcionará con SQLite3.


775
2017-08-25 14:11



Para obtener solo un valor en un valor múltiple INSERT de otra tabla hice lo siguiente en SQLite3:

INSERT INTO column_1 ( val_1, val_from_other_table ) 
VALUES('val_1', (SELECT  val_2 FROM table_2 WHERE val_2 = something))

76
2018-01-10 23:46



Las dos respuestas que veo funcionan bien en Informix específicamente, y son básicamente SQL estándar. Es decir, la notación:

INSERT INTO target_table[(<column-list>)] SELECT ... FROM ...;

funciona bien con Informix y, supongo, con todo el DBMS. (Hace 5 o más años atrás, este es el tipo de cosas que MySQL no siempre soportaba, ahora tiene soporte decente para este tipo de sintaxis SQL estándar y, AFAIK, funcionaría bien en esta notación). La lista de columnas es opcional pero indica las columnas de destino en secuencia, por lo que la primera columna del resultado de SELECT irá a la primera columna de la lista, etc. En ausencia de la lista de columnas, la primera columna del resultado de SELECT entra en el primera columna de la tabla de objetivos.

Lo que puede ser diferente entre sistemas es la notación utilizada para identificar tablas en diferentes bases de datos: el estándar no tiene nada que decir sobre las operaciones entre bases de datos (y mucho menos entre DBMS). Con Informix, puede usar la siguiente notación para identificar una tabla:

[dbase[@server]:][owner.]table

Es decir, puede especificar una base de datos, identificando opcionalmente el servidor que hospeda esa base de datos si no está en el servidor actual, seguido por un propietario opcional, un punto y, finalmente, el nombre real de la tabla. El estándar SQL usa el esquema de término para lo que Informix llama el propietario. Por lo tanto, en Informix, cualquiera de las siguientes notaciones podría identificar una tabla:

table
"owner".table
dbase:table
dbase:owner.table
dbase@server:table
dbase@server:owner.table

El propietario en general no necesita ser citado; sin embargo, si usa comillas, debe obtener el nombre del propietario correctamente escrito: se distingue entre mayúsculas y minúsculas. Es decir:

someone.table
"someone".table
SOMEONE.table

todos identifican la misma tabla Con Informix, existe una leve complicación con las bases de datos MODE ANSI, donde los nombres de los propietarios generalmente se convierten a mayúsculas (informix es la excepción). Es decir, en una base de datos MODE ANSI (no comúnmente utilizada), podría escribir:

CREATE TABLE someone.table ( ... )

y el nombre del propietario en el catálogo del sistema sería "ALGUIEN", en lugar de "alguien". Si encierra el nombre del propietario entre comillas dobles, actúa como un identificador delimitado. Con SQL estándar, los identificadores delimitados se pueden usar en muchos lugares. Con Informix, puede usarlos solo alrededor de nombres de propietarios; en otros contextos, Informix trata las cadenas de comillas simples y de comillas dobles como cadenas, en lugar de separar cadenas de comillas simples como cadenas y cadenas de comillas dobles como identificadores delimitados. (Por supuesto, solo para completar, hay una variable de entorno, DELIMIDENT, que se puede establecer, con cualquier valor, pero Y es más seguro, para indicar que las comillas dobles siempre rodean los identificadores delimitados y las comillas simples siempre envuelven cadenas).

Tenga en cuenta que MS SQL Server logra usar [identificadores delimitados] encerrados entre corchetes. Me parece extraño, y ciertamente no es parte del estándar SQL.


52
2017-09-28 03:18



La mayoría de las bases de datos siguen la sintaxis básica,

INSERT INTO TABLE_NAME
SELECT COL1, COL2 ...
FROM TABLE_YOU_NEED_TO_TAKE_FROM
;

Cada base de datos que he utilizado sigue esta sintaxis, a saber, DB2, SQL Server, MY SQL, PostgresQL


26
2018-04-01 10:09



Para agregar algo en la primera respuesta, cuando solo queremos pocos registros de otra tabla (en este ejemplo, solo uno):

INSERT INTO TABLE1
(COLUMN1, COLUMN2, COLUMN3, COLUMN4) 
VALUES (value1, value2, 
(SELECT COLUMN_TABLE2 
FROM TABLE2
WHERE COLUMN_TABLE2 like "blabla"),
value4);

26
2018-04-09 17:15



Esto se puede hacer sin especificar las columnas en el INSERT INTO parte si está suministrando valores para todas las columnas en el SELECT parte.

Digamos que la tabla 1 tiene dos columnas. Esta consulta debería funcionar:

INSERT INTO table1
SELECT  col1, col2
FROM    table2

Esto NO funcionaría (valor para col2 no está especificado):

INSERT INTO table1
SELECT  col1
FROM    table2

Estoy usando MS SQL Server. No sé cómo funcionan otros RDMS.


22
2017-10-16 14:19