INSERTAR vs INSERTAR EN

He estado trabajando con T-SQL en MS SQL durante algún tiempo y, de alguna manera, siempre que tengo que insertar datos en una tabla, tiendo a usar la sintaxis:

INSERT INTO myTable <something here>

Entiendo que la palabra clave INTOes opcional aquí y no tengo que usarla, pero de alguna manera se convirtió en un hábito en mi caso.

Mi pregunta es:

• ¿Existe alguna implicación de usar INSERTsintaxis versus INSERT INTO?
• ¿Cuál cumple plenamente con la norma?
• ¿Ambos son válidos en otras implementaciones del estándar SQL?

INSERT INTOes el estándar. Aunque INTOes opcional en la mayoría de las implementaciones, es obligatorio en algunas, por lo que es una buena idea incluirlo para garantizar que su código sea portátil.

Puede encontrar enlaces a varias versiones del estándar SQL aquí . Encontré una versión HTML de un estándar anterior aquí .

Son lo mismo, INTOes completamente opcional en T-SQL (otros dialectos SQL pueden diferir).

A diferencia de las otras respuestas, creo que afecta la legibilidad de uso INTO.

Creo que es algo conceptual: en mi percepción, no estoy insertando una fila en una tabla llamada "Cliente", sino que estoy insertando un Cliente . (Esto está relacionado con el hecho de que suelo nombrar mis tablas en singular, no en plural).

Si sigue el primer concepto, INSERT INTO Customerlo más probable es que se "sienta bien" para usted.

Si sigue el segundo concepto, lo más probable es que sea INSERT Customerpara usted.

Puede ser opcional en mySQL, pero es obligatorio en algunos otros DBMS, por ejemplo, Oracle. Entonces SQL será potencialmente más portátil con la palabra clave INTO, por lo que vale.

Una lección que aprendí sobre este tema es que siempre debes mantener la coherencia. Si usa INSERT INTO, no use INSERT también. Si no lo hace, algunos programadores pueden volver a hacer la misma pregunta.

Aquí está mi otro caso de ejemplo relacionado: tuve la oportunidad de actualizar un procedimiento almacenado muy, muy largo en MS SQL 2005. El problema es que se insertaron demasiados datos en una tabla de resultados. Tenía que averiguar de dónde procedían los datos. Traté de averiguar dónde se agregaron nuevos registros. En la sección inicial de SP, vi varios INSERT INTO. Luego intenté encontrar "INSERT INTO" y los actualicé, pero me perdí un lugar donde solo se usó "INSERT". ¡Ese en realidad insertó más de 4k filas de datos vacíos en algunas columnas! Por supuesto, debería buscar INSERT. Sin embargo, eso me pasó a mí. Culpo al programador anterior IDIOT :) :)

En SQL Server 2005, podría tener algo entre INSERT e INTO como esto:

INSERTAR top (5) EN tTable1 SELECT * FROM tTable2;

Aunque funciona sin INTO, prefiero usar INTO para mejorar la legibilidad.

Ambos hacen la misma cosa. INTO es opcional (en T-SQL de SQL Server) pero facilita la legibilidad.

Prefiero usarlo. Mantiene la misma sensación delimitación sintaxis y la legibilidad como otras partes del lenguaje SQL, como group BY, order BY.

Comencé a escribir SQL en ORACLE, así que cuando veo código sin INTO, se ve 'roto' y confuso.

Sí, es sólo mi opinión, y no estoy diciendo que usted debe utilizar siempre INTO. Pero si no lo hace, debe tener en cuenta que muchas otras personas probablemente pensarán lo mismo, especialmente si no han comenzado a crear scripts con implementaciones más nuevas.

Con SQL, creo que también es muy importante darse cuenta de que ESTÁ agregando una FILA a una TABLA y no está trabajando con objetos. Creo que no sería útil para un nuevo desarrollador pensar en las filas / entradas de la tabla SQL como objetos. De nuevo, solo mi opinión.

Si está disponible, utilice la función estándar. No es que alguna vez necesite portabilidad para su base de datos en particular, pero es probable que necesite portabilidad para sus conocimientos de SQL. Un ejemplo particular de T-SQL desagradable es el uso de isnull, use coalesce!