Partamos de la base que hacer que una operación se repita N veces implica siempre el uso de un ciclo, sea cual sea el que uses y sea cual fuere el lenguaje en cuestión.
Es simple lógica: todo proceso que se repite N veces es un ciclo de ejecución...
El problema es que parece que la cosa está un poco confusa. Lo que tu pareces querer expresar es si es posible realizar, como dice jurena, un insert múltiple de registros en un numero limitado de ejecuciones -preferentemente en una sola- y que no dependa del lenguaje.
Veamos:
- Si no se puede modificar el modelo de datos, solamente se puede hacer por la aplicación y allí
juega el lenguaje de programación.
- Si lo deseas hacer fuera del lenguaje, solamente te queda
modificar la base de datos para construir un SP con parámetros adecuados que te permitan hacer el proceso...
en un ciclo repetitivo.
En realidad la cosa, como la estás planteando, se resuelve por código en la aplicación mucho más fácilmente que cualquier otra cosa.
1. Una solución es que, tomando una tabla donde almacenes los datos a insertar, genere una sentencia de SQL de este tipo:
Código sql:
Ver originalINSERT INTO TABLA1(campo1, campo2, campon)
VALUES(valor1, valor2, valorN), (valor1, valor2, valorN), (valor1, valor2, valorN), ..., (valor1, valor2, valorN);
Por cuestiones de performance no es conveniente que los conjuntos de datos sean demasiados, a fin de evitar que el string se vuelva demasiado grande.
2. Otra solución, mucho más compleja y que yo he usado en algunas ocasiones, es crear un conjunto anidado de consultas y subconsultas que me devuelvan la tabla a insertar completa. En ese caso simplemente escribo una sentencia:
Código sql:
Ver originalINSERT INTO x
SELECT *
FORM (subconsultas anidadas) Tabla1;
Esto lo he realizado en algunos casos llegando a ocho (8) niveles de anidamiento con algunos JOIN adicionales. ¿Por qué tan compleja? Porque en el peor escenario me consume 18 segundos de proceso, mientras que hacerlo en la aplicación me insume algo más de un minuto...
Obviamente, en tu caso, para usar la segunda opción los datos primarios deben existir en la base y no en la aplicación.