Rows multiplicados por una columna

[jonyjm]

Hola a todos. tengo una duda que seguramente puedan resolver. Necesitaría hacer una consulta, de forma que 1 fila de una tabla, me de como resultado tantas filas como el numero de una de sus columnas. Me explico:

Tengo 2 registros:

ID | Nombre | Cantidad

1 | Juan | 3
2 | Pedro | 5

Necesitaría una consulta que me de como resultado:

1 | Juan | 1
1 | Juan | 1
1 | Juan | 1
2 | Pedro | 1
2 | Pedro | 1
2 | Pedro | 1
2 | Pedro | 1
2 | Pedro | 1


Me explico?

Gracias por su tiempo.

Saludos

[Heimish2000]

Con un proceso lo puedes hacer. Te creas una tabla temporal y un bucle por cada registro desde uno hasta la cantidad y haces un insert en esa tabla temporal. Luego una select sobre la tabla creada y ya lo tienes.

[jonyjm]

Mmm necesitaría alguna opción (si existe) más rápida. Ahora lo estoy pasando por un procecso, pero es para volcar una tabla con más de 10 millones de registros. Necesito un proceso más rápido que una temporal, y había pensando en un insert select con esta condiciones que te comento.

No se, se me ocurría algo como un join por la clave de la tabla contra ella misma, multiplicado por la columna, pero no termino de darle forma.

Alguna idea?

Saludos y gracias por tu respuesta

[gnzsoloyo]

Alguna idea?

Que nos expliques en qué contexto puedes necesitar generar algo que contiene manifiestamente una redundancia completamente nociva de datos.
ASí como lo planteas, no conozco ningún sistema que requiera algo semejante.

[jonyjm]

Bueno, te cuento.

Tengo una base de datos, con registros de visualizaciones, por id, y un contador de las visualizaaciones, del tipo:

idproducto | cantidad

1 | 100
2 | 250
3 | 120
.
.
.

Tengo que migrar esa tabla, a un nuevo modelo de la misma, que contiene 1 registro por cada visualización, es decir:

idvisualizacion | idproducto | fecha | blablabla

1 | 1 | xxxx | xxxx
2 | 1 | xxxx | xxxx
3 | 1 | xxxx | xxxx
.
.
. y asi hasta 100 registros para el producto 1, 250 para el 2, 120 para el 3, etc...


Me explico mejor ahora?

Obviamente el modelo no es cuestionable ya que viene dado de esta forma en la plataforma que tengo que implementarlo. Como comenté, la migración hoy por hoy se hace con un bucle por cada registro, pero creo que se podría optimizar más, ya que debido al tamaño de la tabla, es
un proceso muy costoso. La tabla resultante, tiene al rededor de 10 millones de registros.

Saludos

[gnzsoloyo]

Bueno, ahora queda más claro, aunque infortunadamente no hay muchas partes por donde resolver el problema.
La cosa tiene dos soluciones:
1) A nivel de SP: Creas un cursor que lea la tabla vieja y procesas uno a uno los registros. Con eso puedes hacer N inserciones si pones las inserciones dentro de un LOOP, que se reinicia con cada FETCH al cursor. En ese caso el LOOP dependerá del valor leído del cursor en el campo correspondiente.
2) A nivel de programación, deberás crear inserts masivos con N registros, los cuales obviamente creas en la programación de una aplicación.
El tema que tienes que tener en cuenta que no hay forma práctica de hacer lo que quieres de otra forma, porque estás hablando de 10.000.000 registros, lo que no veo práctico hacer en un query masivo y recursivo (que de todos modos MySQL no puede hacer porque no existen clausulas que lo permitan).
En el contexto que describes, implicaría un uso enorme de memoria para poder generarlo, cosa que francamente yo estimo que generará errores de transferencia y requerirá indefectiblemente tocar la configuración del servidor.
A mi entender, usar tablas de tipo TEMPORARY y crear bloques en memoria de datos a volcar masivamente, como ya te propusieron y se puede hacer en el primer ejemplo que te digo, sería la mejor opción.
Si los registros son tantos como dices, cualquier camino requerirá bastante tiempo de procesamiento.
Horas, sino al menos un par de días.

Yo he tenido que realizar una tarea bastante parecida en Oracle hace poco, con un volumen mucho menor de registros, aprovechando recursos excelentes del PL/SQL de Oracle, y usando servidores bastante poderosos, y aún así estimamos que en el mejor de los casos nos va a llevar alrededor de un día a un día y medio de procesamiento.

No creo que lo que propones lleve mucho menos de eso, en el mejor de los casos.

[jonyjm]

Gracias por tu respuesta, voy a tener en cuenta los consejos que me dices. Realmente es un proceso muuuy largo, que esta llevando muchísimo tiempo.

Vamos a intentar optimizarlo con tus consejos.

Saludos y gracias nuevamente